Alerts
Alerts are created from incidents and delivered through the integrations linked to a monitor. They can include up to five small reported metrics, but never the full report payload.
Alert model
Scheduled and outbound monitors create an incident when they transition into a failed state. Cronity queues notification work for that incident and fans it out to the enabled integrations linked to the monitor. This prevents every repeated scheduler pass or failed URL check from becoming a new alert.
| Monitor type | Alert trigger |
|---|---|
| Cron / manual | A schedule is missed after its grace period, or an explicit failure is reported |
| Website / API | The configured consecutive-failure threshold is reached |
| Script | Each failed or successful report selected by the monitor’s alert switches |
| Cron recovery | A successful result after a failed state |
| On-demand | A Script or Manual request with alarm=1, when allowed by the account plan |
What an alert contains
- Monitor name and type, status, reason, message, and event time.
- HTTP status for an outbound failure when available.
- Up to five scalar metrics when “Include reported metrics in alerts” is enabled.
- No full event payload and no nested metric objects.
Metric labels and values are shortened to keep messages compact and safe for each channel.
Delivery history and suppression
The Alerts page shows recent delivery attempts and whether they were sent, failed, or skipped. Delivery may be skipped when an integration is disabled, an email recipient is unconfirmed, no channel is linked, or an account/monitor alert allowance has been reached.
Limits use rolling 24-hour windows and depend on the account plan. Failed provider attempts count toward the account delivery allowance as well as successful sends.