---
title: Resolving incidents
description: How incidents close — on recovery, when their source is paused, disabled or deleted, and by hand — how to mark one as a false positive, and how that differs from acknowledging, muting and maintenance windows.
canonical: https://watchfor.io/docs/alerting/resolving
---

# Resolving incidents

How incidents close — on recovery, when their source is paused, disabled or deleted, and by hand — how to mark one as a false positive, and how that differs from acknowledging, muting and maintenance windows.

Most incidents resolve themselves. Some you will want to close by hand.
WatchFor covers both and always tells the channels that were alerted what
happened and why.

**Also via API:** [`POST /v1/incidents/{id}/resolve`](/docs/api/incidents#resolve-an-incident),
[`/acknowledge`](/docs/api/incidents#acknowledge-an-incident) and
[`/exclude`](/docs/api/incidents#mark-an-incident-as-a-false-positive) do the
same from scripts and AI agents, with the same role rules.

## Automatic resolution (recovery)

When the failing condition recovers — the site responds again, the
certificate is renewed, latency drops back — the incident **resolves
automatically** and a recovery notification goes to the same channels that
were alerted (PagerDuty and Opsgenie close their event; chat channels get a
🟢 message, grouped if several recover together).

Recovery needs **three consecutive successful checks** (one for heartbeat
monitors), mirroring the confirmation on the way in, so one lucky response
cannot close a real outage. Because checks run faster while an incident is
open, that usually takes well under a minute after the fix.

Where a failure was confirmed from several locations, recovery is judged the
same way: the incident resolves once enough locations report success — a
single healthy location does not resolve an outage the others still see.

## Resolve on source change

If you change the thing that caused the incident, the incident should not
linger:

- **Pause a monitor** → its open incidents resolve. From the dashboard,
  pausing a monitor that has an open incident **asks you to confirm** first
  and says so; **Mute** is the option that keeps the incident open and only
  silences the notifications. Pausing also clears the monitor's failure
  counters, so the next incident needs the full confirmation threshold
  again — see [Actions on a monitor](/docs/monitors#actions-on-a-monitor).
- **Disable or delete an alert rule** → incidents from that rule resolve.
- **Delete a monitor** → its incidents and history are removed with it.

In each case the channels that were alerted are notified with the reason
("alert rule disabled", "monitor paused") and who did it, and the incident
timeline records the same. Resuming the monitor or re-enabling the rule
starts fresh: if the condition still fails, a new incident is confirmed and
opened.

## Manual resolve

Owners and admins can **Resolve** an incident from its page, from the **⋯**
menu on any row of the [incidents list](/docs/alerting/incidents#acting-from-the-list),
or for several incidents at once by selecting them there — for example when
the fix was verified out of band and you do not want to wait for the next
checks, or when the rule that fired was wrong and you are about to fix it.
Each path asks for confirmation first and explains that a still-failing
condition will simply re-open the incident.

- The original channels get a message saying **who** resolved it and that it
  was resolved manually; the timeline and the
  [activity log](/docs/organization/activity-log) record it.
- If the condition is **still failing**, the incident simply **re-opens** on
  the next confirmed failure — the same approach PagerDuty and Opsgenie take.
  Manual resolve is not a way to silence a monitor; use
  [mute](/docs/notifications#muting-a-monitor) or a
  [maintenance window](/docs/monitors/maintenance) for that.

## Acknowledge, resolve, mute, maintenance

| Action | Who | What it does | Checks | Incident stays open |
| --- | --- | --- | --- | --- |
| **Acknowledge** | any member | "Someone is on it": stops reminders and the escalation chain for this incident | continue | yes, until recovery |
| **Resolve** | owner / admin | Closes the incident now; re-opens on the next confirmed failure | continue | no |
| **Mark as false positive** | owner / admin | Keeps a *resolved* incident on record but takes it out of uptime, SLA, reports and the status page — see [False positives](#false-positives) | continue | already resolved |
| **Mute** (1 h – 7 d) | owner / admin | Silences all notifications from the monitor, including future incidents | continue | yes; incidents keep recording |
| **Maintenance window** | owner / admin | Scheduled silence, optionally excluded from uptime, announced on the status page | continue | yes; badged *Maintenance* |
| **Pause** | owner / admin | Stops the checks; open incidents resolve (the dashboard confirms first when one is open) and the failure counters are cleared | stop | no |

## False positives

Sometimes an incident was real to the checks but not to your users: a
network problem on the path from our locations that made it through
confirmation, a firewall rule that briefly blocked the probes, a threshold
set too tight. Deleting it would lose the timeline and the notes; leaving it
alone dents your uptime and keeps an outage that never happened on your
status page.

Owners and admins can mark a **resolved** incident as a false positive:
**Mark as false positive** on the incident page (with an optional reason),
or tick **This was a false positive — exclude it from uptime** in the
Resolve dialog (the button becomes **Resolve as false positive**) to resolve
and mark in one step. From then on:

- The incident **stays on record** — timeline, root cause,
  [internal notes](/docs/alerting/internal-notes),
  [post-mortem](/docs/alerting/postmortems) and the
  [activity log](/docs/organization/activity-log) entry — with a
  **False positive** badge.
- It **no longer counts as downtime**: uptime, the Uptime SLA tab and
  [reports](/docs/reports) (incident counts, MTTR, downtime) leave it out,
  everywhere, from the moment you mark it.
- It is **removed from your public status page**: the
  [auto-published](/docs/status-pages/updates#auto-published-incidents) copy
  is deleted and the page's uptime history is refreshed.

**Count as downtime again**, on the same page, undoes it — the numbers
include the incident once more. The status-page copy is *not* re-created
(incidents are only auto-published while they fire), so write one by hand if
customers should see it after all.

> **Info**
>
> **False positive is not maintenance.** Both take a resolved incident out
> of uptime, but they say different things. *Mark as maintenance* means
> "the downtime was real, but planned": the period becomes neutral and the
> incident keeps its place in history and on the status page. *False
> positive* means "this was never real downtime": it leaves every
> customer-facing number and page, and only your team still sees it. An
> open incident can't be marked as a false positive — the checks are still
> deciding it — so resolve it first, or use the checkbox in the Resolve
> dialog.

**Also via API:** [`POST /v1/incidents/{id}/exclude`](/docs/api/incidents#mark-an-incident-as-a-false-positive)
and [`/include`](/docs/api/incidents#undo-a-false-positive-mark); incident
objects carry `excluded_from_uptime`, `exclusion_reason`, `excluded_by` and
`excluded_at`.

## After the fact

A resolved incident that should not count against your uptime can be
reclassified in two ways, depending on what it was:

- **Planned work nobody scheduled a window for** — a deploy, a migration —
  is [marked as maintenance](/docs/api/incidents#mark-an-incident-as-maintenance)
  through the API: its time range becomes neutral in uptime and SLA numbers,
  and the incident keeps its place in history and on the status page.
- **Not real downtime at all** is marked as a [false positive](#false-positives).

For anything worth learning from, write a [post-mortem](/docs/alerting/postmortems).

> **Info**
>
> Every acknowledge and resolve — automatic or manual — is on the incident
> timeline and in your [activity log](/docs/organization/activity-log), with
> the actor and the reason.

---

Canonical page: https://watchfor.io/docs/alerting/resolving · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt