11.2What we send

For each alert, obsrvly sends one POST request to each attached webhook channel. Several alerts at once still mean one request per alert. The request has Content-Type: application/json, plus any headers you added.

The payload (the JSON body of one request) is a single flat object with these fields:

Field	Type	Sent with	Meaning
`event`	text	both	`alert.fire` or `alert.resolved` (11.3).
`alert_id`	text	both	The incident: one stretch of time a monitor is failing. It is the same on the first alert, reminders and the recovery.
`monitor_id`	text	both	The monitor. Always sent. On a test it is an empty string.
`monitor_name`	text	both	The monitor's name.
`monitor_url`	text	both	What the monitor checks: its URL, host or domain.
`status`	text	fire	`down` or `degraded`.
`consecutive_failures`	number	fire	How many checks had failed in a row when the alert fired.
`location`	text	fire	The region the failing check ran from, such as `us-west` or `eu-west`. Heartbeats show `inbound`.
`last_error`	text	fire	The check's error message.
`fired_at`	time	fire	When the incident opened. The same on reminders.
`reminder_number`	number	fire	Only on a reminder: `1`, `2`, and so on. Missing on the first `alert.fire`.
`resolved_at`	time	resolved	When the monitor recovered.
`downtime_seconds`	number	resolved, reminders	On `alert.resolved`: how long the monitor was down. On a reminder: how long so far.
`fire_suppressed`	true/false	resolved	`true` when no `alert.fire` was sent for this incident, because the monitor was muted or in a maintenance window.

Times are in UTC, in RFC 3339 format, such as 2026-09-08T14:27:23Z.
Apart from monitor_id, obsrvly leaves out a field when it has no value. A missing field is not an error. For example, fire_suppressed is missing unless it is true.
obsrvly may add new fields. Ignore fields you do not know.