Acknowledge a monitor outage

An outage starts when an HTTP monitor, heartbeat (cron) monitor or browser check goes down. Acknowledging it records who is on it and when. With the default notification settings, it also stops the outage’s repeat alerts, so the team stops being re-paged for something a person already has.

An acknowledgment is about one outage, not the monitor. If the monitor recovers and goes down again, that is a new outage and needs its own acknowledgment.

Where to acknowledge

Where	How
Monitor page	An open outage shows Acknowledge. Afterwards the page reads, for example, “Acknowledged by Sam, 4 minutes ago (via email link)”.
Down alert email	The email carries an acknowledge link. See the email link.
REST	`POST /monitors/{monitor_id}/outages/{transition_id}/acknowledge`. See REST.
AI assistant	The `acknowledge_monitor_outage` MCP tool. See MCP.
The linked incident	Acknowledging the incident the outage opened also acknowledges the outage. See Incidents.

Slack, PagerDuty and the other chat and paging channels carry no acknowledge button for monitor outages.

The rules

The first acknowledgment wins. It is recorded once per outage. Acknowledging again, by anyone and by any route, returns the original acknowledgment unchanged.
An ended outage cannot be acknowledged. Once the monitor has recovered, the request is refused, unless the outage was already acknowledged, in which case you get that acknowledgment back.
Recovery alerts are still sent. Acknowledging never suppresses the all clear.
Repeats stop only when the setting is on. With outage_ack_stops_repeats on (the default), the outage’s repeat alerts stop. With it off, they continue until the monitor recovers.

Repeats come from a notification group’s resend_every_minutes, which applies to down alerts from HTTP monitors, heartbeats and browser checks.

The email link

Down alert emails sent to an email channel carry an acknowledge link, https://api.siteqwality.com/monitors/outage_action/<token>.

Single use. After you press the button, the link is used up.
Expires after 24 hours.
Tied to one outage and one email. The token is made for that outage and the email that carried it.
Recorded as the recipient. The acknowledgment names the address the email was sent to, with source email_link. No user is attached, so the link works without signing in.

Opening the link shows a page that says what will happen and changes nothing; pressing its button acknowledges. The extra step keeps email security scanners, which open every link in a message, from acknowledging an outage on their own. Treat the link like a password: anyone who has it can acknowledge as that address until it is used or expires.

GET /monitors/outage_action/{token} shows the confirmation page and POST /monitors/outage_action/{token} acknowledges. Both are unauthenticated: the token is the credential. They mirror the incident action links.

Incidents opened by the outage

When a monitor linked to a service in auto mode goes down, the outage can open an incident. The two stay in step, in both directions:

Acknowledging the outage acknowledges the incident it opened, as the same person, if the incident is still triggered. That stops its escalation.
Acknowledging that incident, from the incident page, an action link or the API, records the outage acknowledgment with source incident.

Only the incident the outage opened automatically is linked. An incident someone created by hand that lists the monitor is not touched by an outage acknowledgment, and acknowledging it does not acknowledge the outage.

If the service uses the default unless_acknowledged auto-resolve, an acknowledged incident does not resolve itself when the monitor recovers, so acknowledging the outage leaves the incident open for a person to resolve.

REST

Find the outage’s id in GET /monitors/{monitor_id}/alert_history (add kind=cron or kind=browser for those monitors), then acknowledge it. The request has an empty body.

curl -X POST \
  https://api.siteqwality.com/monitors/$MONITOR_ID/outages/$TRANSITION_ID/acknowledge \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY"

To acknowledge whatever outage is open right now without looking up its id, use POST /monitors/{monitor_id}/outages/current/acknowledge. It returns 404 when the monitor has no open outage.

{
  "transition_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "monitor_id": "3f2c8a9e-5b1d-4c7a-9e0f-1a2b3c4d5e6f",
  "monitor_type": "http",
  "acknowledged_at": "2026-10-19T03:15:10Z",
  "acknowledged_by_user_id": "0b4a2f4e-6f3a-4c84-9a52-1d7a6e1c0f11",
  "acknowledged_by_name": "Sam Rivera",
  "source": "api",
  "recipient": null
}

Field	Description
`transition_id`	The outage.
`monitor_id`	The monitor.
`monitor_type`	`http`, `cron` or `browser`.
`acknowledged_at`	When it was recorded.
`acknowledged_by_user_id`	The user, or `null` for an email link.
`acknowledged_by_name`	The user’s name, or `null` for an email link.
`source`	Where it came from: `console` (the dashboard), `api`, `mcp`, `email_link` or `incident` (the linked incident was acknowledged).
`recipient`	The email address for `email_link`, otherwise `null`.

Each outage in GET /monitors/{monitor_id}/alert_history carries acknowledgement: this object once acknowledged, otherwise null.

MCP

The acknowledge_monitor_outage tool takes a monitor_id and an optional transition_id. Without transition_id it acknowledges the monitor’s open outage. The acknowledgment is recorded with source mcp, and get_alert_history shows the result. See Connect AI assistants.

Audit

Acknowledgments appear in the monitor’s alert history and in the customer audit log.