Services reference

Service fields

Field	Type	Default	Notes
`id`	UUID		Read-only.
`name`	string		Required.
`description`	string	none	`null` on update clears it.
`escalation_policy_id`	UUID	none	Who the service’s incidents page. Without one, nobody is paged. Must be a policy in your account (`404` otherwise). `null` on update clears it.
`incident_creation_mode`	`manual`, `auto`	`manual`	`auto_with_confirmation` is still accepted on input and treated as `auto`, but is never returned.
`reopen_window_minutes`	integer	`30` for new services	`0` to `1440`. A monitor that fails again within this many minutes of the last alert of a resolved auto-created incident reopens it instead of opening a new one. `0` never reopens. See reopen window.
`auto_resolve`	`always`, `unless_acknowledged`, `never`	`unless_acknowledged`	Whether an auto-created incident resolves itself when all its monitors recover. `unless_acknowledged` leaves an acknowledged incident for a person to resolve. See auto-resolve.
`incident_merge_window_minutes`	integer	none	Deprecated and ignored. While an auto-created incident is open, every failing monitor of the service joins it.
`default_incident_severity`	`minor`, `major`, `critical`	`minor`	Severity of incidents the service opens automatically.
`auto_publish_to_status_page_id`	UUID	none	Puts automatic incidents on this status page and emails its subscribers. `null` on update clears it.
`public_incident_template`	object	none	`{ "title", "message", "resolved_message" }`, each optional: the public title, first public update and resolved update for this service’s incidents on a status page. Values are trimmed and blank ones dropped. The title is at most 512 characters and each message 5,000 (`400` otherwise). Leaving it out keeps it; `null` clears it. Omitted from responses when empty.
`monitor_count`	integer		Read-only. Linked HTTP monitors and heartbeats; browser checks are not counted.
`created_at`	RFC 3339		Read-only.

Endpoints

Method	Path	What it does
`GET`	`/service`	List services.
`POST`	`/service`	Create a service.
`GET`	`/service/{id}`	Fetch one service.
`PUT`	`/service/{id}`	Update the fields you send.
`DELETE`	`/service/{id}`	Delete the service and its broadcast targets. Linked monitors are not unlinked. Needs an admin, or an API key with `write:services`: other roles get `403`.
`GET`	`/service/{id}/monitors`	List linked monitors as `{ id, name, monitor_type }`, where `monitor_type` is `http` or `cron`.
`PUT`	`/service/{id}/monitors`	Replace the linked set with `{ "http_job_ids": [...], "cron_job_ids": [...] }`. A list you leave out is treated as empty.
`GET`	`/service/{id}/notification_target`	List broadcast targets.
`POST`	`/service/{id}/notification_target`	Add a broadcast target.
`DELETE`	`/service/{id}/notification_target/{target_id}`	Remove a broadcast target.

Linking monitors

PUT /service/{id}/monitors unlinks every HTTP monitor and heartbeat currently on the service, then links the IDs you send. To add one monitor, send the full list including the ones already linked. An ID that is not a monitor in your account returns 404, and nothing changes.

Browser checks link through their own service_id field on POST /browser_check and PUT /browser_check/{id}. New HTTP monitors accept an optional service_id on POST /http/job; an unknown or foreign service ID returns 404 before a monitor is created. Change an existing HTTP monitor’s assignment through the service form or PUT /service/{id}/monitors.

Broadcast targets

Create one with type and details:

`type`	`details`	Notes
`email`	`{ "email": "oncall@example.com" }`	Any address.
`slack_channel`	`{ "slack_token": "xoxb-...", "channel": "#incidents" }`	A Slack bot token you supply, not the Slack integration. The token is write-only: it reads back as `"has_token": true`.
`webhook`	`{ "url": "https://hooks.example.com/incidents" }`	Must be a public URL. It reads back as its scheme and host only, such as `https://hooks.example.com/****`. Uses the webhook envelope and retry schedule, unsigned, and does not appear in the integration’s delivery log.

curl -X POST https://api.siteqwality.com/service/$SERVICE_ID/notification_target \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "type": "webhook", "details": { "url": "https://hooks.example.com/incidents" } }'

When targets are told

Every lifecycle event below is sent to the service’s broadcast targets. The last column is what the Slack, email and webhook targets deliver today:

Event	Happens when	Delivered today
Opened	An incident opens on the service, automatically or by hand.	Yes
Resolved	An incident on the service resolves.	Yes
Acknowledged	A responder acknowledges it.	Recorded
Updated	An update is posted, or the severity or title changes.	Recorded
Reopened	A resolved incident reopens.	Recorded
Merged	An incident is merged into another.	Recorded
Service changed	An incident moves to another service.	Recorded

A recorded event starts delivering as each channel’s message for it ships. A monitor recovering while the incident stays open sends nothing, and an incident merged into another sends no resolved message. An update posted as an internal note is marked internal on its event. Status page subscribers only ever get public updates.

Automatic incidents

Behaviour	Value
Sources	Linked HTTP monitors and heartbeats; browser checks with this `service_id`.
Title	`<monitor name> is down`
Severity	`default_incident_severity`
Skipped when	A maintenance window matching the monitor’s tags is active, or the service is `manual`.
One open incident	The service has at most one open auto-created incident. Every failing monitor joins it, recorded as a `monitor_joined` timeline event.
Reopened when	A monitor fails again within `reopen_window_minutes` of the last alert of the resolved incident.
Resolved when	Every monitor on the incident (HTTP, heartbeat and browser checks) is healthy again, and `auto_resolve` allows it.
Paged	Right after the incident is recorded. If that is interrupted, a sweep pages it within about a minute.