Services

A service is a named part of your product, such as Checkout API or Marketing site. It ties monitors to incident handling:

which monitors belong to it;
whether a failing monitor opens an incident on its own;
which escalation policy pages people for its incidents;
the severity those incidents start with;
who else is told when an incident opens (broadcast targets).

Services are the only way a monitor failure becomes an incident, and the only way an incident pages anyone. A monitor with no service still sends its monitor alerts through its notification groups, but it never opens an incident.

Create a service

Open Manage → Services and choose + Add Service.
Give it a name and, optionally, a description.
Pick an escalation policy. Without one, the service’s incidents page nobody.
Pick an incident creation mode (see below) and a default severity.
Set how long a resolved incident can reopen (the reopen window, 30 minutes for a new service; 0 never reopens) and when an incident resolves itself (auto-resolve; unless_acknowledged by default).
Choose the HTTP monitors and cron monitors (heartbeats) that belong to the service, and save.

Or via the API:

curl -X POST https://api.siteqwality.com/service \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Checkout API",
    "escalation_policy_id": "<policy-id>",
    "incident_creation_mode": "auto",
    "reopen_window_minutes": 30,
    "auto_resolve": "unless_acknowledged",
    "default_incident_severity": "major"
  }'

Incident creation modes

Mode	What a failing linked monitor does
`manual` (default)	Nothing. You open incidents yourself; one you attach to the service still pages its policy and tells its broadcast targets.
`auto`	Opens the service’s auto-created incident, or joins it if one is already open. See auto-created incidents.

HTTP monitors open incidents only after their own confirmation settings pass, and heartbeats and browser checks are always treated as confirmed. The old auto_with_confirmation mode is gone: the API still accepts it on input, treats it as auto, and never returns it.

Auto-created incidents

A service in auto mode has at most one open auto-created incident. The first linked monitor to fail opens it, titled <monitor name> is down. While it is open, every other failing monitor of the service joins it instead of opening a second one. Each join adds a monitor_joined event to the timeline, and each monitor records when it joined and when it recovered; see affected monitors and impact.

The incident starts at the service’s default severity and pages the service’s escalation policy as soon as it is recorded. If that is interrupted, a sweep pages it within about a minute. It is skipped while a maintenance window matching the monitor’s tags is active.

HTTP, heartbeat and browser checks all count: the incident counts as recovered when every one of its monitors is healthy again.

Reopen window

When an auto-created incident has resolved, a monitor that fails again within reopen_window_minutes of the incident’s last alert reopens that incident instead of opening a new one. A later failure opens a new incident.

The window runs from 0 to 1440 minutes. New services start at 30. 0 never reopens: every failure after a resolve opens a new incident.

Auto-resolve

When every monitor on the incident has recovered, auto_resolve decides whether it resolves itself and stops the escalation:

Value	What happens
`always`	The incident resolves itself.
`unless_acknowledged` (default)	It resolves itself unless someone acknowledged it. An acknowledged incident stays open for a person to resolve.
`never`	It stays open until someone resolves it.

Link monitors

Monitor type	How to link it
HTTP monitors	Choose Service when creating the monitor, send `service_id` on `POST /http/job`, or use the service form and `PUT /service/{id}/monitors`.
Heartbeat (cron) monitors	On the service form, or `PUT /service/{id}/monitors`.
Browser checks	Set `service_id` when you create or update the browser check through the API. They do not appear in the service’s monitor list or count.
DNS, TLS, domain, page speed, RUM and alert rules	Cannot be linked. They never open incidents.

A monitor belongs to at most one service. Linking it to a second service moves it without warning.

Broadcast targets

A broadcast target tells someone outside the escalation chain about the service’s incidents. There are three types:

Email: any address.
Slack channel: a Slack bot token and channel that you paste in. It does not use the Slack integration. The token is write-only and is never shown again.
Webhook: a public URL. Deliveries use the webhook envelope with incident.created and incident.resolved events, but they are not signed.

Incident lifecycle events go to the service’s broadcast targets: opened, acknowledged, updated (an update posted, or the severity or title changed), resolved, reopened, merged and service changed. Today the Slack, email and webhook targets deliver opened and resolved. The other events are recorded, and start delivering as each channel’s message for them ships.

An incident merged into another sends no resolved message. An update posted as an internal note is marked internal on its event, while status page subscribers only ever get public updates.

Add targets on the service’s detail page in the dashboard (it opens from a monitor or incident linked to the service), or through the API. See the reference.

Publish incidents to a status page

Auto-publish to Status Page (auto_publish_to_status_page_id) puts every incident the service opens automatically on that status page and emails the page’s subscribers that it opened.

The public incident template (public_incident_template) words what customers read, so a monitor’s name or an internal hostname never reaches the page:

Public incident title: the title the page shows. Without one, an automatic incident shows “Service disruption”.
First public update: posted when the incident is published. Without one: “We are investigating this issue.”
Resolved update: posted when it resolves. Without one: “This incident has been resolved.”

The template also prefills Publish for the service’s manual incidents. Set both on the service form in the dashboard, or through the API.

Deleting a service

Only admins, or an API key with write:services, can delete a service. Deleting it removes its broadcast targets and detaches its incidents, but linked monitors keep pointing at the deleted service. Unlink them first by sending empty lists to PUT /service/{id}/monitors.