SPspectate
Alerts

Resolve an alert

Ends the alert by hand, as if its problem were over: its escalation stops, the channels and on-call members it notified hear that it resolved, Slack and Telegram show it as resolved by the API token, and status pages automated from an uptime alert show the monitor as recovered. Use it for false alarms, or for alerts whose source can't tell they're over.

If the problem is still there, the source fires a new alert at its next check (a monitor that is still down, a host metric still over its limit). Resolving a resolved alert changes nothing.

post/alerts/{alert}/resolve

Request

  • Base URL
    https://api.spectate.net/v1
  • Auth
    HTTP bearer

Path parameters

alertstring uuid required

Alert ID.

Response

The resolved alert.

idstring uuid required

Alert ID

titlestring required

What's wrong

descriptionstring nullable required

More about it, as the source described it

status'firing' | 'resolved' required

Whether an alert's problem is ongoing.

firing <br/> The problem is ongoing; it escalates until acknowledged.
resolved <br/> The problem is over.
severity'critical' | 'high' | 'medium' | 'low' required

How urgent an alert or incident is. Escalation paths can branch on it.

critical <br/> Customers are affected right now.
high <br/> Serious, needs attention soon.
medium <br/> Should be looked at.
low <br/> Informational.
source_type'uptime' | 'certificate' | 'performance' | 'dns' | 'host_metric' | 'domain' | 'external' | 'status_page' | 'manual' required

What raised an alert.

uptime <br/> A monitor went down.
certificate <br/> A monitor's certificate is invalid or expires soon.
performance <br/> A monitor got slow.
dns <br/> The answer of a DNS monitor changed (when it alerts on changes), or a nameserver has a problem that leaves its monitor up.
host_metric <br/> A host's metric condition held, or it stopped sending data.
domain <br/> A domain expires soon, expired or its registration changed.
external <br/> An alert source (external tool) fired it.
status_page <br/> Visitor issue reports over the threshold or a traffic spike (metadata.type: issue_reports, traffic_spike).
manual <br/> Someone paged by hand, with nothing else to attach it to.
fired_atstring date-time required

When it fired

acknowledged_atstring date-time nullable required

When it was acknowledged, which stopped its escalation; null while unacknowledged

acknowledged_bystring nullable required

Who acknowledged it: a member's name, an API token, or how (for example a phone call)

recovering_sincestring date-time nullable required

When the monitor came back up. The alert stays firing for the team's recovery wait and resolves when the monitor stays up; null at any other time

group_leader_idstring uuid nullable required

The alert that escalates for this one, when they're grouped; null when it escalates by itself

snoozed_untilstring date-time nullable required

Until when someone snoozed it; null when it isn't snoozed. It counts as acknowledged until then

muted_atstring date-time nullable required

When maintenance muted it, so it pages nobody until the window ends; null when it isn't muted

resolved_atstring date-time nullable required

When it resolved; null while firing

resolved_bystring nullable required

Who resolved it by hand: a member's name or an API token. null while firing, and when it resolved on its own because the problem was over

labelsobject nullable required

Labels the source sent (Prometheus, Grafana); null when it sent none

Example response

{
  "title": "Website is down",
  "resource": {
    "name": "Website"
  },
  "acknowledged_by": "Jane Doe",
  "resolved_by": "Jane Doe",
  "links": [
    {
      "label": "View issue in Sentry"
    }
  ]
}

Changes

No recorded changes to this operation across all 1 revision of this API.