# How Built replaced PagerDuty and got the full incident management lifecycle for the same price * **Same cost as PagerDuty alone, full incident lifecycle included** * **~50 platform engineers** across the cloud platform team * **8-person incident manager rotation** freed from manual timeline assembly --- Built's incident management looked fine on the surface: PagerDuty for paging, Slack automations creating tickets and spinning up channels. But everything after that first alert was manual. A senior SRE was brought in with one constraint: fix it without spending more. They chose incident.io over Rootly and FireHydrant, got the full incident lifecycle for roughly what they'd been paying PagerDuty for alerting alone, and ran it on the first incident that came in. ### PagerDuty paged people. It didn't help them respond. The setup looked reasonable on paper. But everything after the initial alert is where it fell apart. > We had Slack automations that would create a Jira ticket, spin up the incident room, and page the people through PagerDuty who were on call. We built that whole orchestration through Slack. Everything after the initial alert (documentation, timelines, follow-ups, post-mortems) was entirely manual. Incident managers had to create Confluence pages from scratch, follow templates from memory, chase action items, and reconstruct what happened by scrolling through Slack history. **The incidents ended. The work didn't.** Jacob Weyer, Manager of the Cloud Platform Team, was spending an hour or two after his workday ended on paperwork after major incidents: manually assembling timelines, logging decisions, following up on actions. Engineering time spent on paperwork isn't neutral. It delays the work that reduces future incidents, and it burns people out. ### Everyone pitched in. Nobody owned it. Built didn't have a dedicated owner for incident management. "It was more of a committee of people doing things on their best effort," Paul explains. When they hired a senior staff SRE to own it properly, the mandate was clear: find a platform that covered the entire incident lifecycle, not just paging, without increasing spend. --- ## The decision ### Do more for the same money The SRE's mandate wasn't to throw budget at the problem. It was to optimize the process. > We brought in incident.io for roughly what we were paying for PagerDuty. Except now we had the full incident management lifecycle. That was the big ROI. Jacob led the vendor evaluation, comparing [incident.io](http://incident.io) against Rootly and FireHydrant. Two things separated [incident.io](http://incident.io): the licensing model and how deeply Slack-native the experience was. > We loved how it managed incidents through Slack, meeting us where we already are. PagerDuty had done its job.But stitching together the rest of the incident lifecycle around it carried a cost, both financially and in tooling complexity, that was too large to ignore. > There were a couple of things that stood out about incident.io compared to the competitors: the licensing model and how Slack-native the process was. We were okay with leaving PagerDuty. It wasn't really special to us. --- ## The migration ### Day one: they jumped right in The PagerDuty renewal was coming up. Rather than renew, Built went month-to-month and started using [incident.io](http://incident.io) immediately. The platform was intuitive enough to run incidents out of the box, and they did, from day one. > We essentially just cut over. Whatever the first incident was, we just started using the tool. It wasn't perfectly configured; we had to tinker and figure things out as we went, but we started immediately handling incidents with incident.io. Workflows got refined, configurations got dialed in, and the platform grew with them. The learning happened in production, not in a staging environment. On-call came next, moving across team by team until PagerDuty was no longer needed. ### Training happened once. The system handled everything after. The initial rollout included real training and knowledge transfer. But once the process lived in the tool, it stopped needing to be managed. > Incident managers don't need to know every step. The system prompts them and drives them through it. When your process lives in a tool rather than a doc, it actually gets followed. Before, a process change meant an announcement. Now the tool just reflects it. The next incident, the tool reflects it. There's no announcement, no retraining needed. When the process changes, the team doesn't have to stop and absorb it. They just run a better incident. > Before, we were managing all of our incident management responses in Confluence, pretty manual and hard to follow. Now we've been able to codify that with incident.io, centralize it, and automate what actually happens. Throughout the rollout, the [incident.io](http://incident.io) team was a message away in Slack. They were answering configuration questions, helping refine workflows, and making sure nothing fell through the cracks. --- ## The impact ### Less paperwork, more signal Ask anyone on the incident manager rotation what changed most: the post-incident paperwork that used to consume hours simply stopped. > As an incident manager, I can focus on the incident and not the paperwork. I can focus on the problem. I don't have to worry about documenting the steps that we did; I can have it auto-generated. That has been just night and day. Timeline generation now happens automatically from Slack history and call transcripts. What used to be a post-incident obligation became something that looked after itself. And the same data that freed Jacob gave Paul something he hadn't had before: visibility without presence. > I don't have to join every call to understand what's going on when the team's working it. The reporting gives me visibility into what happened, who was involved, how long it ran. Before [incident.io](http://incident.io), that data was scattered across Jira tickets and Confluence docs. Pulling it together for any meaningful analysis was a manual exercise. Now it's a dashboard. > Almost all of it used to be a manual process: the timelines, the follow-ups, all of it. The platform changed that. Every time a new feature lands, it gets harder to imagine running incidents any other way. --- ## What Paul would tell another engineering leader > You need a full incident management suite, not just an on-call and escalation tool. That makes a whole world of difference, being able to build your process around the tool versus just adopting something that manages one part of the lifecycle. --- ## Looking forward Built has adopted [incident.io](http://incident.io)'s status pages and is evaluating internal status pages for their larger customers. With the reactive side under control, Jacob is already thinking about the next frontier. AI SRE is where he's looking. > We're focused on solving problems before they happen: agentic remediation, removing the human from the loop, keeping our processes and systems running.