Stephen Whitworth’s first production deployment made rather more of an impression than he intended. He had taught himself enough programming to move a model into a live service. Then the service began creating subscribers, crashing, and creating more subscribers. Within seconds, the messaging system was overwhelmed. His introduction to shipping software included an outage.
He expected to be fired. Instead, he encountered the practice of examining a failure to improve the system around it. The episode became an early lesson in what happens when a promising piece of code meets production. There are dependencies, unexpected interactions, and other people. The code gets the publicity. The other people get the call.
Years later, Whitworth would co-found incident.io, where he is CEO. Its starting question was what an engineer needs once an alert has arrived. Someone must investigate, colleagues need updates, customers need answers, and a record needs keeping. An alarm can announce the beginning of all this with admirable efficiency. It leaves a considerable amount of employment for everyone else.
A model has to leave the notebook
Whitworth’s route into engineering began in data analysis. He worked at the taxi business Hailo and learned to code as his work moved toward data science. Models could predict things; making those predictions useful inside a product required another set of skills. He crossed into the part of the job where software has to run.
At Queen Mary University of London, he studied from 2010 to 2013 and graduated with first-class honours. His later technical career was built through practice. Before incident.io came Ravelin, the fraud detection business he co-founded with former colleagues from Hailo. There, the consequences of a prediction were immediate: allow a transaction, or treat it as suspicious.
His work involved the machinery around machine learning as much as the models themselves. Signals had to be extracted, data prepared, performance evaluated, and improved models deployed. Rules and graph networks sat alongside machine learning. The job demanded a working system in which several approaches could contribute to a decision.
Forbes included him in its 2018 Europe 30 Under 30 technology list as a Ravelin co-founder. Alongside the company work, his public technical footprint includes GoLearn, a machine-learning library for the Go programming language. The repository makes the engineering part of his biography unusually concrete. It is available to inspect, with its code, examples, and history attached.
He also began explaining the work. His newsletter, High Growth Engineering, examined the odd circumstances of building software in companies that kept expanding. How should teams share knowledge as new engineers arrive? How should they maintain code while priorities change? In its biography, he described a career that had moved through engineering, data science, machine learning, and some product management.
By then, he was a senior software engineer at Monzo, working on financial crime. His interests extended beyond whether a system functioned. He was writing about how people understood it, improved it, and worked together around it. Those questions would occupy much of his next company.
Three colleagues, one unfinished job
At Monzo, Chris Evans had built internal tooling to organise incident response. It was subsequently open-sourced. Whitworth, Evans, and Pete Hamilton saw companies spending engineering time recreating similar machinery. Buying useful software for the job ought to have been possible. They began building incident.io together and founded the company in 2021.
Each brought experience of software going wrong, though they had not spent their Monzo careers working closely as a trio. Evans’s internal tool supplied a practical starting point: the coordination work could be organised. Whitworth brought experience of operating consequential systems, including the fraud detection decisions that Ravelin made in the path of a payment.
The early company occupied a former London fire station. For a business concerned with incidents, the address supplied its own running joke. More consequentially, the founders were selling something that needed to behave convincingly when everything around it was misbehaving. Their own demonstrations were capable of supplying a rehearsal.
During an early presentation to GoCardless, the demo failed. Hamilton kept talking while Whitworth repaired the account behind the scenes. A change to configurable incident roles had reached other accounts but missed the demonstration account. Whitworth fixed the data, and the presentation continued. The company had briefly provided an unusually thorough demonstration of its subject matter.
- 01AssembleBring the right people together.
- 02InvestigateWork out what changed and what broke.
- 03CommunicateKeep colleagues and customers informed.
- 04LearnRecord decisions and carry out follow-ups.
Whitworth’s early writing widened the subject beyond engineering. In June 2021, he argued for incident management across an organisation. Support teams, commercial colleagues, and other departments had a place in the response. A technical fault could create work well beyond the people able to repair it.
That view gave incident.io a larger brief than sending notifications. An incident creates a temporary organisation inside the organisation: people need responsibilities, information, and a way to see what has already happened. His argument was that the practices useful to engineering could help the rest of the business participate, too.
The day everyone stopped to write
In March 2022, Whitworth described a company habit that sounds improbable during the early life of a software startup. Once a month, everyone put aside their usual work and spent a day writing. Ideas were collected in Notion beforehand. Meetings were cleared. Colleagues reviewed and edited each other’s drafts.
He called it Content Day. At the company’s size that February, it produced roughly 10 to 15 articles. The writing could cover technical work, hiring, customer experience, or the mechanics of building the business. Giving everyone time helped bring more viewpoints into public view.
“There’s few things more important in a company than communicating well.”
Stephen Whitworth, writing about Content Day, 2022
He described the costs as well. A synchronised writing day could interrupt someone’s flow. Editing required effort. The arrangement might become cumbersome with a much larger staff. He was describing a practice that suited an early company, with trade-offs attached. Writing had a place on the calendar, and that place was open to examination.
An ocean in the working week
By August 2022, the company had announced a New York office. Whitworth’s explanation began with customers: a substantial share of the business was already in the United States. He wanted the American operation to have real weight, including commercial leadership and a team able to build a shared culture.
He was blunt about the investment involved. A few people in a shared office, maintained at conversational distance over video, would be a poor basis for the expansion he envisaged. The US presence needed money, time, and people who could establish how the company worked.
Whitworth joined that work himself. By the company’s 2023 Barcelona offsite recap, he had relocated from London to New York. The American team had grown to seven people. Expansion, in his case, had acquired the ordinary particulars of a move: a different working day, different relationships, and an ocean between parts of the company.
In November 2024, he announced a San Francisco office alongside the existing London and New York presence. The reasons were practical. Customers were nearby, commercial candidates were concentrated in the Bay Area, and the location would extend support coverage. He described being able to walk between several large customers’ offices in an afternoon.
When he later discussed US expansion, the personal detail was as revealing as the commercial logic. “Hiring employees is very different from making friends,” he said. Recruiting could help build the business. A life in a new country needed its own attention. Even a founder accustomed to solving problems could not put both tasks into the same hiring pipeline.
A bigger job for the software
The product kept expanding, too. Response was followed by Status Pages, then On-call in March 2024. In his launch announcement, Whitworth described schedules, escalation paths, and ways for teammates to arrange cover. The person carrying the phone had obligations beyond the rota. The product needed to accommodate them.
In April 2025, Whitworth announced a $62 million Series B led by Insight Partners, bringing announced total funding above $96 million. The next investment included agents that could help investigate incidents. Customers named in the announcement included Netflix, Etsy, OpenAI, and Airbnb. The company’s responsibilities were growing with its reach.
His discussion of AI included a familiar engineering difficulty: a persuasive demonstration could work for one customer and still fail to generalise. During a July 2025 interview, he stressed the need for precision. An incorrect suggestion during an outage could divert a responder at exactly the moment attention was scarce.
By August 2026, incident.io was introducing Investigations powered by Nexus. The company described an investigation system that continued working as evidence arrived, connected its hypotheses to supporting material, and allowed engineers to question its reasoning. Nexus supplied a model of an organisation’s systems and incident history. The ambition had moved further into diagnosis.
That brings Whitworth back to the problem his early deployment exposed. Software operates amid dependencies and partial knowledge. People must decide what to trust and what to do next. His career has repeatedly put him close to those decisions, first through models and fraud detection, then through the coordination of an entire response.
The alert still matters. Someone must know that something has broken. Whitworth has spent the years since his own first deployment building toward a more useful arrival: a responder who can see what happened, who is helping, and where to begin.
Keep the conversation going
Watch the conversations
Read on