Back to blog
2 min read
IncidentsGuide

How long should an incident stay open after the site recovers?

Auto-resolve is not the same as done. Close when customer impact is gone and the next on-call would not be confused, not the second a single check turns green.

NK

Nabin Khair

Founder

The site is answering again. Slack wants a green checkmark. Someone asks if they can go back to bed. How long you keep the incident open is a judgment call with real consequences.

Mitigated vs resolved

Mitigated: customers can work; you may still be on a failover, a feature flag, or a fragile hotfix.
Resolved: normal path restored, or you have consciously accepted the new normal and documented it.

If you close at mitigated every time, the next flap opens a confusing new incident. If you never close, the board fills with zombies.

A practical rule

For availability incidents driven by monitors:

  1. Require sustained success, not one lucky green check. Two or three consecutive successes, or a short soak window, before auto-resolve.
  2. Keep the incident open if you are still in an active maintenance or risky follow-up deploy.
  3. Close when on-call would not need to keep a laptop warm for that issue.

Tallwatch and similar tools auto-resolve when checks recover. That is good default behavior. Humans should still post a resolve note on the status page and capture anything unfinished for daylight.

Flapping

If the monitor is bouncing, do not play whack-a-mole with open/close. Either widen confirmation, fix the check, or keep one incident open until the underlying instability stops. Twelve incidents in an hour teach everyone to ignore the thirteenth.

Customer communication

Public "resolved" should mean they are unblocked, not that your process doc is complete. If a postmortem is coming, say so. Do not hold the resolve banner hostage for the essay.

Stay open long enough to be honest. Close soon enough that on-call can sleep. The exact minutes depend on how jumpy the system is; define a soak habit for your team and reuse it.

Keep reading

More from the Tallwatch blog

More on monitoring, alerting, and status pages.