Incident: an instance of something happening; an event or occurrence.

Incident has become a dirty word in engineering. It is shorthand for “something broke and we need to fix it urgently”. However, there is something really powerful about calling an incident at most companies. Incidents encourage engineering to have a singular focus and to begin using a well-exercised process and communication strategy that drives towards an outcome (usually a fix).

We recently renamed the company from Gitpod to Ona, with a launch event which took place on September 2nd. Although we had done beta testing, this was our “grand unveiling” of not just a new company, but new services too (Ona Agents, Ona Cloud).

I wanted to ensure that engineering was really focused on stability and correctness during this launch event. I wanted to ensure communication was centralized and clear.

Time to call an incident?

Launches as Incidents: Reframing the Narrative

A couple of hours before the launch I ran a command that usually I dread running; I typed /incidentinto Slack and hit enter.

There was no dread today; just excitement as we sprang into action to enable a bunch of feature flags and merge many PRs labelled [DO NOT MERGE UNTIL LAUNCH] or something of that nature.

Declaring the launch as an incident gave us:

• A single, central thread of communication. Everyone knew where to look, and no one got lost pinging in random Slack threads.
  
• Clear roles and ownership. Engineers had named systems to watch (Stripe fraud rules, Grafana dashboards, agent executions) and knew exactly who’d respond if something spiked.
  
• Proactive alerting and escalation. With a follow-the-sun on-call rotation, we triaged fast and didn’t wait for someone to notice things breaking.

It felt strange at first, but once you think of an incident as a way to exercise a well understood process to drive clarity, It might be you can apply it to more situations than you thought.

Incidents within Incidents

We did ultimately experience some minor “typical” incidents during launch day too. For really small issues, we kept them contained to the main incident room and resolved them on a thread. For things that we needed to follow up on later, we used Incident.io’s follow up feature to quickly make notes.

However, when things required a tiny bit more focus, we created a new incident and I would shuffle updates back and forth between rooms so everyone else could remain focused.

Final Thoughts

If your team sees incident management as a reactive (and maybe even negative) process — try flipping the script. Use incident tooling to coordinate your highest-stakes, highest-visibility moments. We were pleasantly surprised by how well this worked, and I think you will too.

The next time you’re shipping something big, consider declaring it an incident — not because something is broken, but because you’re building something that needs clarity, focus, and ownership.

Let the incident framework, which is likely well understood within your company, do the heavy lifting.