Incident lifecycle
How an incident moves from detected to resolved, who can close it, and what to do with one you've dealt with.
The stages
Detected — status "draft"
Written the moment detection fires: a sales anomaly at 1:00 AM UTC, or an outage after two failed checks. It appears in your dashboard immediately, with no ranked causes yet.
If it is critical, the alert email goes out at this point — before causes exist. That is why the email says what happened and links you to the page for why.
Explained — within 30 minutes
The correlation job picks it up, scores the changes in the preceding 24 hours, and writes ranked causes and linked evidence. Nothing about this stage notifies you; the incident page simply has more on it next time you look.
Open
The working state. It shows in the list, counts toward the sidebar badge, and can make a site's health read "Degraded".
Investigating
Set by ChangeTrace support when someone is actively looking — usually after you have used the Need help? widget.
Resolved
Closed, with a resolution time. Outage incidents reach this on their own. Sales incidents do not.
Who can close an incident
There is no resolve button, and that is on purpose for now
Outage incidents close themselves the moment your site responds again — that is an objective fact ChangeTrace can verify.
A sales incident has no equivalent. "Revenue recovered" and "the drop was expected" are very different things, and neither is something ChangeTrace can observe. Rather than offer a button that means whatever you decide it means, closing is handled by ChangeTrace support — who also use it to check how accurate the detection is.
In practice: an incident you have dealt with can simply be left. It stops being the "active" one on your Overview as soon as a newer one arrives, and filtering the list by status hides it. If a stale incident is genuinely in your way, ask through Need help? and it will be resolved or marked a false positive.
Duplicates
You will not get two incidents for the same thing. Each carries a fingerprint of site, metric and day, so a detector re-run never creates a second row — and because emails fire only on genuinely new incidents, you are never emailed twice about one.
A new day with a continuing drop does open a new incident. A week-long slump produces a series, not one long one.
False positives
They happen, and the common causes are mundane:
- A one-off promotion ended
- A public holiday
- A deliberate change — ads paused, a product retired
- A shop far from UTC, where a "day" straddles two local ones
If you get them regularly, the fixes are: ask support to mark them false positives (which feeds back into accuracy), or raise your alert threshold so only bigger drops reach your inbox. Email alerts →
How long incidents stick around
Incidents outlive the raw events behind them. Events and metrics are deleted at your plan's history window — 7 days on Free — so an old incident may keep its title and ranked causes while its underlying timeline has aged out.
If an incident matters, capture what you need from it while the data is fresh. Data, privacy & retention →

