Alerting

Configure alert channels and rules — email, Slack, Discord, Telegram, and webhooks — with quiet hours and escalation.

Alerts are how SteadyCron tells you something went wrong. You define channels (where alerts go) and rules (which events, on which jobs, go to which channel).

Channels

Connect one or more delivery channels:

  • Email — available on every plan.
  • Slack — post to a channel via an incoming webhook.
  • Discord — post to a channel via a webhook.
  • Telegram — message a chat via a bot.
  • Webhook — POST a JSON payload to any endpoint you control, for custom routing (PagerDuty, Opsgenie, your own handler).

Slack, Discord, and Telegram require a paid plan. You can send a test alert to a channel to confirm it’s wired up correctly.

Triggers

A rule fires on one or more events:

  • On failure — a run failed (or a heartbeat reported /fail).
  • On N consecutive failures — only alert once a job has failed repeatedly, to cut noise.
  • On missed heartbeat — an expected ping didn’t arrive within the grace period.
  • On recovery — the job is healthy again (auto-resolves the incident).

Runbook notes

Every job can carry a runbook: a short markdown note (and optionally a link to a fuller doc — Notion, Confluence, your internal wiki) with the exact steps to fix it. Set it once on the job; when an alert fires, the runbook is embedded directly in the notification — Slack, Telegram, and email all show it inline.

Step 1: Check replication lag on node-2 (SELECT now() - pg_last_xact_replay_timestamp()).
Step 2: If lag > 5 min, fail over via `make db-failover`.
Step 3: Re-run this job manually from the dashboard once caught up.

At 3am, the page doesn’t just say “Job X failed” — it tells whoever’s on call what to do next, without them having to find the runbook first.

Reducing noise

SteadyCron shapes delivery so you’re not buried in notifications:

  • Deduplication — repeated alerts for the same condition are collapsed within a window.
  • Flapping detection — jobs that toggle up/down rapidly are flagged rather than alerting on every transition.
  • Quiet hours — suppress non-critical alerts during set hours (paid plans).
  • Escalation — if an alert isn’t resolved, escalate to another channel (Team plan).

Reliability

Alerts are written atomically alongside the event that triggered them and delivered by a separate dispatcher with retries, so a notification is never silently lost — even if a delivery target is temporarily down.

Next steps