The Tool Sprawl Problem: Why Engineering Teams End Up Running Three Incident Tools

Nobody plans to run three incident tools. You start with an uptime checker because the homepage should not go down unnoticed. A year later, someone misses a Slack alert overnight, so you add PagerDuty or Opsgenie. A customer asks where to check status during an outage, so you stand up Statuspage or Freshstatus. Each decision is reasonable in isolation. Together they become a stack you operate as much as you operate your product.

I have been the person with three tabs open during an incident, trying to remember which tool owns the truth this minute. The monitor is red in one product. The page went to the wrong rotation in another. The status page still says all systems operational because nobody has clicked update yet. That is tool sprawl in practice.

The typical three-tool stack

For a lot of 20 to 50 person companies, the stack looks like this.

1. Better Uptime, UptimeRobot, or a similar product for HTTP checks and basic alerting.
2. PagerDuty or Opsgenie for on-call schedules, escalation, and phone or push pages.
3. Atlassian Statuspage or Freshstatus for customer-facing communication.

Sometimes the monitoring tool sends email, the pager owns SMS, and the status page is updated by whoever remembers the login. Integrations exist on paper. Under pressure, a human is still the integration layer.

You end up here because vendors specialize. Uptime tools are good at checks. Pagers are good at waking people. Status products are good at public communication. Buying best-of-breed pieces feels responsible until you have to keep those pieces aligned every time a service, rotation, or severity rule changes.

What the stack costs at about 20 engineers

Prices move, and every vendor has packaging tricks, but a realistic monthly picture for a 20-person engineering org looks roughly like this.

| Piece | Typical shape | Ballpark monthly cost | | --- | --- | --- | | Uptime monitoring | Team plan, dozens of monitors, a few regions | $50 to $180 | | On-call and paging | Per-user or per-responder pricing for ~15 to 20 people | $400 to $900 | | Status page | Starter or growth plan with subscribers and branding | $30 to $150 | | Combined | Three contracts, three admins | about $500 to $1,200 |

The cash cost is not the only bill. Someone has to own SSO, user offboarding, monitor-to-pager webhooks, and status page component mapping. That work rarely shows up as a line item. It shows up as the engineering manager who is still the only person who knows how the webhook auth works.

Per-responder pricing also punishes growth. Add five engineers to the rotation and the pager bill jumps even if your monitor count stays flat. That incentive quietly pushes teams to keep people off the tool, which is the opposite of what you want from an on-call system.

Where the stack breaks under pressure

Alert routing gets duplicated by hand

A monitor fires in tool A. Tool B is what can actually reach the on-call phone. Somewhere between them sits a webhook, an email relay, or a Zap that someone configured eighteen months ago. When you add a service or change a severity, you update the monitor and hope the pager side still matches.

I have seen the failure mode where monitoring knows the API is down and PagerDuty is healthy because the integration user was deactivated. The red check sits there looking obvious in hindsight. Nobody was paged.

Postmortem data never lives in one place

The alert timeline is in PagerDuty. The real discussion is in Slack. The customer-facing history is in Statuspage. The deploy marker is in GitHub Actions. When you write the postmortem two days later, you reconstruct a timeline from four products and human memory. Timestamps disagree. Acknowledgements are missing. The status page updates were late, so the public history understates how long customers waited for an honest signal.

A postmortem built from memory is how contributing factors get lost. The tools each have a slice of the truth. None of them has the incident.

Status pages lag because updates are manual

In the three-tool world, a monitor failure does not automatically become a status component change. Someone has to notice, decide the wording, log into the status product, and publish. During a real outage that person is also debugging. The page stays green until restore is near, which trains customers to ignore it.

Automatic status updates require a clean binding between monitor state and public components. That binding is awkward when monitoring and status live in different vendors with different service taxonomies.

Onboarding becomes a scavenger hunt

A new engineer needs accounts in three products, notification rules in the pager, understanding of which monitors map to which services, and a reminder that the status page is a separate login with separate components. Your runbook starts with "make sure you are in all three tools" before it ever says how to mitigate the payment API.

Offboarding is worse. Remove someone from GitHub and Google Workspace, forget the pager seat, and you are still paying for a user who cannot help you, or worse, still receiving pages on a personal number.

The vendor dependency you do not notice until renewal

With three vendors, any renewal can hold the rest of the stack hostage. The pager raises prices, and suddenly you are renegotiating while your monitors and status page still depend on that pager's routing. Migrating one slice means rewiring the seams again.

You also inherit three uptime stories, three support desks, and three ways incident history can disappear if a contract lapses. Operational risk hides inside procurement.

What a unified platform changes in practice

A unified incident platform does not magically create good process. It removes the handoffs that make average process fail.

Single alert routing config. The monitor, the severity, the schedule, and the escalation path are one configuration surface. Change the service owner once.

Status page updates from monitor state. When a check fails and an incident opens, the matching public component can move without a separate login ritual. Humans still write the narrative. The "we know something is wrong" signal does not wait on that prose.

Postmortem timeline from the same record. Alert fired, ack landed, status changed, restore confirmed. Those events already exist in one incident object. The write-up starts from that timeline instead of a forensic scavenger hunt across vendors.

One place to onboard and offboard. Seats, schedules, and monitor access follow the workspace, not three identity graphs.

Vigiles is one example of that model. Monitoring, on-call, status pages, and incident learning share a workspace on flat pricing, so you are not paying a per-responder tax to keep the pager wired to the checks. Other unified tools exist. The architectural point is the same. Fewer seams under pressure beat a collage of specialized tabs.

A quick audit before you rip anything out

You do not need a migration plan on day one. You need a clear picture of the seams.

Ask four questions after your next incident.

1. Which product fired the first trustworthy signal?
2. Which product actually reached a human on a phone?
3. Which product did customers see, and when was it updated relative to detection?
4. Where did you build the postmortem timeline from?

If the answers are four different systems, sprawl is not theoretical. Map the webhooks and shared secrets next. Anything that only one engineer can reconfigure is an operational risk sitting next to your uptime checks.

When you evaluate a unified option, score it on those four paths, not on a feature matrix. Feature parity theater is how teams stay on three tools forever.

Shrink the stack on purpose

If your incident tooling grew the organic way, you are not behind. You are normal. The question is whether the seams are now costing more than the specialized features are worth.

Count the monthly spend. Count the integrations that only one person understands. Count the minutes in your last incident that went to tool coordination instead of mitigation. If those numbers sting, the fix is not a fourth tool. It is collapsing detection, routing, communication, and learning onto one timeline your team actually trusts.