Schedules and alerts
Schedules
A check takes a five-field cron expression in UTC. Free runs every 15 minutes at the tightest; paid plans every minute. Set the check's default env first, usually just BASE_URL, because scheduled runs pass nothing else. A run that is still going when the next slot arrives is skipped, not queued, so a slow check cannot pile up behind itself.
flarely configure <checkId> --base-url https://www.example.com --cron "*/5 * * * *"
Incidents
Only monitoring runs move incidents: schedules and production deploys. A first failure triggers one immediate re-run. If that fails too, an incident opens and every channel in the project hears about it. Further failures bump a count without re-alerting. The next pass resolves the incident and sends a recovery message. Manual, CI and agent runs never page anyone.
Incidents carry a fingerprint of the file, test, failed step and message, so the same break groups together.
Channels
| Kind | Plan | Notes |
|---|---|---|
| Free and up | One address per channel. | |
| Slack | Solo and up | An incoming webhook URL. Block Kit message with the failing step. |
| Webhook | Team | JSON body, X-Flarely-Event header, and X-Flarely-Signature: sha256=<hmac> when you set a secret. HTTPS, public hosts only. |
Webhook URLs and secrets are encrypted at rest and never returned by the API. Use "Test" on a channel to see a message before the first incident.