There’s a version of this story that starts with a dramatic production outage, a panicked Slack channel, and a team scrambling to find the runbook while customers are hitting a broken service. That’s the compelling founder origin story.
The real version is more mundane and, I think, more honest: I kept running into the same problem across different clients and projects. Teams that needed proper incident management and status communication were either paying enterprise prices they couldn’t justify, or piecing together a status page, a separate runbook wiki, and a manual incident log that nobody kept up to date. The gap between “basic uptime checker” and “Atlassian Statuspage contract” was enormous, and almost everyone I knew was living in it uncomfortably.
So I started building Faultline.
The Pricing Problem Is Real, But It’s Not the Real Problem
Let me be clear about what Faultline is not: it’s not a cheaper Statuspage. Price was the forcing function — existing tools price out smaller teams, agencies, and independent product teams almost by design — but if the only thing Faultline offered was the same feature set at a lower price point, it would be competing on a dimension that’s easy to lose.
The more interesting problem, and the one I kept running into, is structural.
Every major status page tool treats incident management and runbooks as separate concerns. Your public-facing status page lives in one place. Your internal runbooks — the step-by-step procedures your team follows when something breaks — live somewhere else entirely. Notion, Confluence, a shared Google Drive folder, a README nobody has updated since 2022. When an incident happens, you’re managing two systems simultaneously: updating the status page that your users are watching, and hunting through your documentation system for the runbook that’s supposed to tell you what to do next.
That’s not an incident management workflow. That’s two jobs that happen to coincide when things go wrong.
Runbooks as an Afterthought
The way most tools handle runbooks — when they handle them at all — tells you a lot about how the industry thinks about incident response.
Runbooks in most platforms are documentation. They’re a place to write down procedures. They sit in a sidebar, or a separate tab, or a linked external document. The assumption is that the status page is the product, and runbooks are supporting material.
That assumption gets the relationship backwards.
When a system goes down, the first thing an on-call engineer needs is not a place to post a public update. It’s a clear, current, executable set of steps to diagnose and resolve the issue. The status update is important, but it’s downstream of the response. Treating runbooks as a documentation feature rather than a core workflow primitive means you’ve optimised for the communication layer at the expense of the operational layer.
In Faultline, runbooks are first-class citizens. They’re not documentation that lives adjacent to an incident. They’re part of the incident itself — surfaced automatically when an incident is opened, linked directly to the affected services and components, executable as a checklist within the incident timeline. The status page update and the internal response workflow are the same system, not two products running in parallel.
What the Gap Actually Looks Like
To understand who Faultline is for, it helps to look at the actual market topology.
At the top end, you have Atlassian Statuspage, PagerDuty, and the enterprise tier of BetterStack. These are fully-featured, well-built products. They’re also priced, integrated, and positioned for organisations with a dedicated platform team, an existing enterprise tooling stack, and the operational maturity to implement them properly. For a 5-person startup, a boutique agency managing a dozen client systems, or a mid-size product team that’s outgrown their static status page, these tools are expensive, complex, and frequently more than they need.
At the bottom end, there are uptime monitoring tools, simple static status pages, and open-source options that require self-hosting, configuration, and ongoing maintenance. They’re cheap or free. They’re also genuinely incomplete — they’ll tell you something is down, but they don’t give you a workflow for managing the response or communicating clearly with users during an incident.
The gap between those two tiers is where most real teams live. They need more than a green/red uptime checker. They don’t need — or can’t justify — an enterprise contract. And they definitely need their runbooks connected to their incidents, not filed in a wiki that someone updates quarterly.
Faultline is being built for that gap.
How It’s Being Built
The architecture is purpose-built around the operational pattern rather than retrofitted from an existing category.
Incidents, components, runbooks, and status updates are modelled as first-class entities with explicit relationships. An incident is associated with the components it affects, the runbook it triggers, the timeline of status updates, and the resolution state — all in a single data model rather than linked across separate systems.
The runbook engine supports structured step-by-step procedures that can be executed as a checklist within an active incident, with each step timestamped and attributed. This creates an automatic incident audit trail — not as a separate logging exercise, but as a natural byproduct of the team actually doing their job.
The public status page is generated from that same data model in real time. When an engineer marks a component as degraded and opens an incident, the public-facing status updates automatically. The internal workflow and the external communication are the same action, not two coordinated actions happening in parallel.
Analytics are designed in from the ground up rather than added as a reporting layer. Every incident will carry structured data: time to acknowledge, time to resolve, which components were affected, which runbook steps were executed, and where the response slowed down. Over time, that data surfaces patterns — recurring failure modes, components with disproportionate incident rates, runbooks that need updating because they’re consistently being deviated from in practice.
What This Means for the Industry
The status page market is going to split.
The enterprise end will continue consolidating around the major players. PagerDuty and Atlassian will keep competing for the same large customers, adding complexity and integrations to justify their pricing tiers.
What the enterprise tools will not do is serve the middle of the market well. The economics don’t support it — a 10-person product team isn’t a meaningful revenue target for a company sized to sell to Fortune 500 procurement teams, and the product complexity that enterprise customers require makes the tools actively worse for smaller teams.
That middle of the market is large and underserved, and it has a specific need that the current generation of tools consistently fails to meet: incident management that connects the operational layer — runbooks, response procedures, internal coordination — to the communication layer — public status, user updates, post-mortems — in a single coherent workflow.
The fragmented approach — status page here, runbooks there, incident log somewhere else — is a product of how the category evolved, not how incident response actually works. Faultline is built around the workflow as it actually exists: something breaks, the team needs to know what to do, and users need to know what’s happening. Those three things belong in the same system.
What’s Coming
Faultline is currently in pre-launch development. The near-term build is focused on depth over breadth: a robust runbook engine, real-time status page generation from incident data, and pattern analytics that make recurring failure modes visible over time.
The goal is not to become another all-in-one observability platform that tries to replace every tool in the stack. It’s to be the definitive place to manage and communicate around incidents — with runbooks that are part of the response, not stored nearby.
If you’re currently managing incidents with a status page in one tab and a wiki in another, Faultline was built with you in mind.
Early access opens Q3 2026. Join the list at fltln.io to be first in and follow the build as it progresses.
Faultline is being developed by Augmented Webcraft. Questions or early feedback? Get in touch.