Logical service grouping
Group HTTP, cron and browser monitors into named services (payments API, checkout flow, authentication) so your team thinks in services, not individual URLs and ports.
Service Catalog
Every service,
Every service,
with a response plan.
Group your monitors into the services your team runs, then decide what happens when one fails: which escalation policy pages someone, whether an incident opens on its own, and which status page it is published to.
Free tier included
No credit card
2-minute setup
Think in services, not URLs.
A service is the unit your team actually talks about: payments, checkout, authentication. Link its HTTP, cron and browser monitors, give it an escalation policy and incident settings, and every failure on any of those monitors follows the same plan.
Escalation built in
Give each service an escalation policy. Its levels can target people or on-call schedules, so a failure pages whoever is on shift without anyone looking it up.
Automatic incidents
Let a monitor failure open an incident on its service at the severity you choose. Failures inside the merge window join the open incident instead of starting a new one.
Recovery closes the loop
When every monitor behind an automatic incident is healthy again, the incident resolves itself and its escalation stops, so nobody has to remember to close it.
Status page integration
Set a status page on a service through the API, and the incidents it opens automatically are published there, so customers see the problem without anyone copying it over. There is no dashboard setting for this yet.
Service notifications
Send a service's incident notifications to its own email address, webhook or Slack channel, alongside whoever the escalation policy pages. A Slack channel target needs a Slack bot token pasted into the target.
One plan per service
A failure that already
A failure that already
knows where to go.
Every monitor linked to a service follows its plan. The incident opens with the right severity, the escalation policy pages the right person, and the status page you set gets the incident, without anyone deciding in the moment.
- Incident creation: automatic or manual
- A merge window keeps one outage from opening ten incidents
- Default severity of minor, major or critical per service
checkout · incident InvestigatingLIVE
SERVICEcheckout
SEVERITYMajor
FAILURES MERGED3
incident opened09:42
policy level 1 paged09:42
published to status page09:42
acknowledged09:46
Manage as code
Script the catalog
Script the catalog
with the REST API.
Create services, link their monitors, and set their escalation policy and
incident settings through the REST API. Keep the script in your repo, and
changes go through your normal pull-request process (reviewed, approved,
applied) instead of hand edits in a UI. A scoped API key needs
read:services to read the catalog and write:services to
change it; a full-access key covers both.
- Full service CRUD via the REST API
- Link monitors to a service in one call
- Diff-friendly: PR review shows exactly what changed
register a service$ curl -X POST https://api.siteqwality.com/service \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"payments-service","escalation_policy_id":"$EP","incident_creation_mode":"auto","default_incident_severity":"major"}'
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"payments-service","escalation_policy_id":"$EP","incident_creation_mode":"auto","default_incident_severity":"major"}'
1
place for a service's monitors, escalation and incident settings
0
manual steps to route an incident to the right team
3
default severities a service can set: minor, major or critical
$0
free tier, service catalog included from the start
FAQ
A service is a named group of HTTP, cron and browser monitors. It carries an escalation policy, incident settings (creation mode, merge window and default severity), optional notification targets, and optionally a status page for its incidents, set through the API. It's how your team thinks about your infrastructure, not how your infrastructure is physically arranged.
It depends on the service's incident mode. In automatic mode an incident opens straight away; in manual mode it waits for you to declare it. A failure inside the merge window joins the incident that is already open. Automatic incidents fire the service's escalation policy and, if the service has one set, appear on its status page.
No. A service records its monitors, escalation policy and incident settings. Who gets paged comes from the escalation policy and the on-call schedules it targets. Dependencies between services are not modelled.
Yes. Set a status page on the service through the API, and the incidents it opens automatically are published there. Status page subscribers are not emailed for these automatic incidents.
Yes. Services, their linked monitors and their notification targets are all managed through the REST API, so a script in your repo can keep the catalog in step with what you run.
Related features
Start free. No credit card.
Uptime, cron, synthetic, logs, RUM, incidents, and status pages. Free tier on every product.