What is incident response?

Which questions does an incident raise all at once?

A prototype has no incidents, only bugs. With paying users, a broken release at 11pm is an incident, and the questions arrive all at once: who noticed, who decides to roll back, who tells customers, and is any data affected? A team that answers those questions for the first time during the incident loses the most time.

What does an incident response plan look like for a small team?

For a small team, an incident response plan is five things decided in advance: who gets the alert and who backs them up, how to stop the damage quickly, where to talk and who is in charge, how customers hear updates, and a blameless write-up afterwards that prevents a repeat.

1. Alerts reach a named person, with a backup.
2. A way to stop the damage quickly: roll back, or switch the feature off.
3. A place to talk and a person in charge.
4. Status updates to customers, even when the news is "we are on it".
5. A blameless write-up afterwards, with the changes that prevent a repeat.

For security incidents, NIST's guidance (SP 800-61 Revision 3, April 2025) is the standard reference, and a data breach can carry legal notification duties, so decide in advance who makes that call. Revision 3 replaced the 2012 Revision 2 and folds incident response into an organization's wider cybersecurity risk management, with the aim of preparing for incidents, reducing their number and damage, and making detection, response and recovery more effective.

When should you declare an incident?

Earlier than feels necessary. Google's SRE book says it is better to declare early and stand down than to start the process hours into a growing problem. Its rule of thumb: declare one if a second team is needed to fix it, if customers can see the outage, or if the issue is still unsolved after an hour of work.

Who does what during an incident?

The SRE book splits the work into four roles so nobody does everything at once: an incident commander, operations, communication and planning. On a two-person team one person may hold several, but naming them still helps. Each role below has one clear job.

• Incident commander: holds the overall picture, assigns the work and keeps any role not handed out.
• Operations: the only people changing the system while the incident runs.
• Communication: sends regular updates to the team and to customers.
• Planning: files follow-up bugs, arranges handoffs and records what was changed so it can be undone.

The commander keeps a live incident document that several people can edit, with the most important facts at the top, and keeps it afterwards for the write-up. Command is handed over explicitly, and everyone is told who leads.

What does incident response look like in a Lovable or Supabase app?

The quickest ways to stop damage are the ones built before you need them: a feature flag to switch off a broken feature, a previous release to roll back to, and point-in-time recovery if bad data was written. The SRE book's priorities apply as they are: stop the damage, restore service, and keep the evidence for the root cause.

If none of these exist in your app yet, our vibe coding rescue puts them in place, and the production readiness check shows which are missing.

What mistakes slow down incident response?

Incident response slows down when several people change production at once, when customers hear nothing while the fix is found, when the plan was written once and never practised, and when postmortems blame a person. Each of these costs time during the incident or honesty afterwards, as the list below explains.

• Several people changing production at once, so nobody knows which change helped.
• Silence towards customers while the fix is found.
• A plan written once and never practised. The SRE book recommends using the process routinely so it becomes second nature.
• Postmortems that blame a person, which teaches people to hide problems.