Alerts

Alerts and escalation

Contacts, routing rules, escalation steps, acknowledgement and quiet hours.

Contacts

A contact is a destination: an email address, a Telegram chat, a Slack or Discord webhook, a generic webhook URL, a second email address for escalation. Contacts belong to the account and optionally to a client workspace.

Channel	Plan	Notes
Email	Free	Up to 10 addresses per contact
Discord, Google Chat	Free	Incoming webhook URL
Telegram	Starter	Personal chats and groups, with an acknowledge button
Slack, Microsoft Teams, Mattermost	Starter	Incoming webhook URL
Webhook	Pro	Signed JSON POST, see payloads
Zapier, PagerDuty	Agency

Routing

Each monitor has a list of contacts. If the list is empty, the account’s default contacts are used. Client-workspace monitors use the workspace defaults first.

Escalation (Pro and above)

Every alert contact can have a delay before it is notified. A chain of contacts with growing delays is an escalation policy, and there is nothing else to configure and no per-message charge. For example, on one monitor:

Immediately: e-mail (no delay)
After 1 minute: Slack
After 5 minutes: PagerDuty

Each channel still needs its own plan, see the table above. A delayed contact is notified only if the incident is still open and has not been acknowledged by then. Acknowledging the incident (button in Telegram or email, the link in the alert, or the API) cancels the pending notifications, and so does recovery. Recovery notifications go immediately to every contact that received the down alert.

Contacts that belong to a client workspace are notified after the workspace’s client alert delay (30 minutes by default), so the agency hears about a problem first.

Notification content

Alerts include the monitor name, URL, error summary, the regions that confirmed, status code and response excerpt, resolved IP, and a link to the incident. Recovery alerts include downtime duration.

Quiet hours and maintenance

Maintenance windows (one-off or recurring) suppress alerts and exclude downtime from uptime figures. Quiet hours per contact delay non-critical notifications (SSL warnings, response-time alerts) to the next morning; downtime alerts are never delayed.

Flap protection

A monitor must be confirmed down by the region quorum (2 of 2 live regions) to open an incident and confirmed up by the same quorum to close it. A site flapping every 30 seconds produces one incident with multiple state changes recorded inside it.