--- title: Mark an incident as a false positive description: When a glitch on the probe side or a threshold set too tight slipped through confirmation, the incident it opened dented your uptime and sat on your status… canonical: https://watchfor.io/changelog/2026-09-04-incident-false-positive --- [All updates](/changelog/page/5#2026-09-04-incident-false-positive) ✨ New Sep 4, 2026 · v 6.7.3 # Mark an incident as a false positive When a glitch on the probe side or a threshold set too tight slipped through confirmation, the incident it opened dented your uptime and sat on your status page, with no honest way to say it was never real. A resolved incident can now be marked as a false positive: it stays on record (timeline, notes, post-mortem) but leaves your uptime, SLA and reports and is removed from the public status page. Owners and admins find it on the incident page, or as a checkbox when resolving by hand; Count as downtime again undoes it. Mark as maintenance remains for downtime that was real but planned. Add a reason; it is shown on the incident and in the activity log. The incident keeps its timeline and root cause, and Count as downtime again undoes the mark. ## When to use it Confirmation from several locations stops most false alarms, but not all of them. A firewall rule that blocked monitoring traffic for four minutes, a network problem between our locations and your server, or a response-time threshold set too tight can all open an incident for a service your users never saw fail. Deleting it would lose the timeline; keeping it costs you uptime you never lost. ## What marking does - The incident stays on record : timeline, root cause, internal notes, post-mortem and the activity log entry, with a False positive badge. - It stops counting as downtime in uptime, the Uptime SLA tab and reports. - It is removed from your public status page , and the page's uptime history is refreshed. - Count as downtime again undoes it. The status-page copy is not re-created, so post one by hand if customers should see it after all. ## Example At 10:08 your Public API monitor opens a critical incident because three checks in a row get HTTP 403. Your own logs show normal traffic the whole time: a new WAF rule on your side was blocking monitoring requests. Once it is resolved, you mark it as a false positive and write that reason. The four and a half minutes come back to your uptime, the outage disappears from the status page, and your team keeps the timeline. ## Who and where Owners and admins, on a resolved incident's page ( Mark as false positive , with an optional reason), or in one step with the checkbox in the Resolve dialog. For downtime that was real but planned, use Mark as maintenance instead. Through the API it is POST /v1/incidents/{id}/exclude . Read more in [False positives](/docs/alerting/resolving#false-positives). Share this update --- Canonical page: https://watchfor.io/changelog/2026-09-04-incident-false-positive · Site guide: https://watchfor.io/llms.txt