How alerting works

Follow the alert lifecycle

1. A probe reports a failure. The monitor records the result from the regions selected for that monitor.
2. GetPulseCheck evaluates confirmation. The incident includes the failing-region count, confirming regions, and a confidence indicator so responders can judge the signal in context.
3. An alert is dispatched. When alerts are enabled and a delivery channel is configured, GetPulseCheck builds the failure payload and sends it to the selected channels.
4. The incident recovers. When the incident is resolved, GetPulseCheck can send a recovery notification if recovery notifications are enabled.

Choose when notifications are sent

• Turn on Enable Alertsin the monitor's alert configuration.
• Choose an alert schedule: Always, Business hours, or Weekdays.
• Set a notification cooldown from 1 to 1,440 minutes. The default is 30 minutes.
• Keep Recovery notifications enabled when responders should receive a second message after the incident closes.

Why repeated requests do not create duplicate alerts

Notification processing records separate sent timestamps for the alert and the recovery. If the same incident notification is requested again after its timestamp is set, GetPulseCheck acknowledges the request without sending the same message again.

What responders can see

Alert payloads can include the monitor target and type, failure reason, HTTP status code, response time, failure streak, confirming regions, confidence, timestamps, and a link to the incident. Recovery payloads add the outage duration, resolution time, and affected regions.

Related

• Email alerts
• Slack notifications
• Webhooks
• PagerDuty integration
• Testing alerts and recovery
• Managing monitors