Configure services
Connect a monitored system to an escalation policy and control repeated alerts.
Create a service
- Open Services and choose the create action.
- Enter a clear name and a description of what is monitored.
- Choose an escalation policy, if available.
- Configure incident deduplication.
- Save.
Click a service row to open its edit view. You can edit and save directly; there is no separate read-only view to pass through.
Connect the right responders
Select an escalation policy in Escalation routing. The policy contains the direct agents and schedules used for that service. To connect a schedule, add it to a policy level and assign that policy to the service.
A service uses one policy at a time. If no policy is selected, there are no configured escalation targets. Policy configuration does not currently activate outgoing notifications.
Copy the public service ID
The API uses the service’s permanent 32-character hexadecimal ID. Copy it from the service edit page and pass it as service_id.
This ID is generated when the service is created and cannot be edited. A numeric ID appearing in a page URL is not the public API identifier. A service ID from another organisation cannot be used with your API credentials.
Configure deduplication
With deduplication enabled, incoming API triggers can join an existing triggered or acknowledged incident within the configured window:
- No explicit key: match the service, regardless of title.
- Explicit key: match that service and key.
The window is measured from the incident’s creation time. Repeated alerts do not restart the window. Resolved incidents do not receive new triggers through deduplication.
For example, with a 120-second window, ten keyless reports received in 50 seconds for the same service become one incident with ten timeline entries. A report after the window may create another incident even if an older one remains open.
See Deduplication and retries for examples and idempotency.
Active status versus health
Active/inactive controls whether the public API accepts new trigger reports for the service. Health reflects open incidents: triggered incidents indicate critical health; acknowledged incidents indicate degraded health; no open incidents indicate operational health.
Marking a service inactive does not resolve its existing incidents. Acknowledge or resolve those incidents separately.
Delete a service
A service with incident history cannot be deleted. Mark it inactive to preserve that history. If you need to remove a service with no history, use its delete action and confirm the selected service.