Chris Evans & Pete Hamilton: Incident.io cofounders
Incident.io cofounders Chris Evans and Pete Hamilton explain why they began on Heroku, how incident culture shaped a playful brand, and why an AI responder should give humans superpowers rather than confidently take control.
Pete Hamilton and Chris Evans are cofounders of Incident.io, a platform for coordinating the people, communication and follow-up involved in responding to incidents.
They trace the product from their own incident work at Monzo through early infrastructure shortcuts, a brand built around the emotional reality of outages, the measurable value of fast feedback loops and a deliberately human-in-the-loop approach to AI.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Where did Incident.io choose to begin in the incident lifecycle?
Paging tools already woke someone up, but the next stage was still messy: a bleary-eyed responder entered Slack and had to find the right people, coordinate work and communicate clearly while everything was on fire. We began with that response gap. Owning paging, response and post-incident work later made it possible to join the full lifecycle together instead of leaving customers to glue tools together with scripts and bots.
Why does incident response require more than fixing the technical fault?
The repair can be only the tip of the iceberg. Responders carry the pressure of a major service being unavailable while coordinating teams, updating people and satisfying legal or organizational processes. At a company such as Netflix, an incident call can involve around 60 people who may never have met. Streamlining context, communication and coordination matters precisely because the technical problem is already stressful.
Why did an incident-management company start on Heroku?
In the early days the question was whether the product worked, not whether its infrastructure would serve a billion users. Heroku let us push code and deploy with very little ceremony, and it carried us much further than expected. Experience scaling systems gave us confidence that we would recognize the moment to migrate. That shortcut created a huge acceleration while the company searched for paying customers and product-market fit.
What should an early DevTools team deliberately leave undone?
Before customers, we focused almost maniacally on the product. Logs and Sentry were enough to debug problems, while elaborate monitoring and infrastructure could wait. Some early code contained consciously ugly shortcuts that would be unacceptable at today’s scale. The standard changes once hundreds of customers and billions of requests depend on you; building for that future before demand exists can prevent you from reaching it.
How did incident culture become part of the brand?
Incidents are serious and emotionally intense, so a judicious bit of humor can release pressure once the immediate danger is under control. Our language grew naturally from how we spoke—personal, playful and free of corporate jargon—and then spread into the product, marketing, events and people we hired. “Move fast when you break things” works because it reflects a culture we have lived rather than a persona invented for a campaign.
Does building for your past self replace customer research?
It is a cheat code, but it can also be a curse. We can quickly judge whether something would have helped when running engineering teams, and our fascination with incidents keeps us studying the domain deeply. That same confidence can tempt us to skip validation and occasionally get things wrong. Lived experience accelerates decisions; it does not make customers unnecessary.
What did the MacBook experiment reveal about developer speed?
A request for new laptops turned into a deliberately over-the-top analysis that reached Hacker News. The useful by-product was instrumentation for local build performance, which let us see whether a growing application was slowing engineers down. Build time bounds how many changes someone can test in a day. We now revisit it regularly because shortening the path from “works on my machine” to production helps a team ship more.
Where has generative AI already proved useful in incidents?
Incident conversations are a rich body of language, so summarizing them, drafting updates and extracting follow-up actions are natural applications. Within a few months, roughly 60% of shared updates had been drafted by the AI feature. A person still reviews what will be sent, which keeps the useful time saving while sharply limiting the risk of a confident but incorrect update.
What should an AI incident responder actually do?
The near-term goal is a brilliant partner, not an overconfident engineer who takes over while production burns. It can search thousands of previous incidents, inspect alerts, code changes and dashboards in parallel, orient a responder and suggest the next step. Humans should validate and act. Each new source of context removes another bottleneck and gives responders superpowers without pretending they are ready to be replaced.
What is your advice to other DevTools founders?
Do not neglect user experience: utility alone does not erase the difference between a tool people tolerate and one they enjoy. Express the care inside a technical product through everything people can see. And charge as early as possible. Someone entering a credit card proves the product is valuable rather than merely interesting, and a customer base of paying users makes product decisions much more focused.
Links & references
- Pete Hamilton on X ↗
- Chris Evans on X ↗
- Incident.io ↗
- The festive MacBooks experiment ↗
- The flight plan that brought UK airspace to its knees ↗
- How Netflix drives reliability across its organization ↗
This episode is brought to you by WorkOS.