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:
- Require sustained success, not one lucky green check. Two or three consecutive successes, or a short soak window, before auto-resolve.
- Keep the incident open if you are still in an active maintenance or risky follow-up deploy.
- 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.
