Docs

The short version

Cronbell watches for a job going silent, not for it going wrong.

You give Cronbell a URL. Your job hits that URL when it finishes. If the URL doesn't get hit on schedule, Cronbell assumes the job failed and emails you — a cron job that silently stops running, a backup script that crashes before it finishes, a CI step that never even started.

Set it up (2 minutes)

1. Create a monitor. Give it a name and how often the job should run.
2. Copy its ping URL. Found on the monitor's page.
3. Add one line to your job — a curl to that URL, only on success.

That's the whole integration. No agent, no library, just one HTTP request at the end of a job you already have.

Copy-paste examples

Cron (bash)

* * * * * /path/to/backup.sh && curl -fsS https://pulsecheck-shivam.fly.dev/ping/<token>

The && is the whole trick: the ping only fires if backup.sh exits 0.

Docker entrypoint

#!/bin/sh
set -e
/app/run-nightly-job.sh
curl -fsS https://pulsecheck-shivam.fly.dev/ping/<token>

Kubernetes CronJob

spec:
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: your-image
              command:
                - sh
                - -c
                - "/app/run.sh && curl -fsS https://pulsecheck-shivam.fly.dev/ping/<token>"
          restartPolicy: Never

GitHub Actions

- name: Run scheduled task
  run: ./scripts/nightly.sh

- name: Report success to Cronbell
  if: success()
  run: curl -fsS https://pulsecheck-shivam.fly.dev/ping/<token>

systemd timer

[Service]
ExecStart=/usr/local/bin/run-job.sh
ExecStartPost=/usr/bin/curl -fsS https://pulsecheck-shivam.fly.dev/ping/<token>

Airflow DAG

def notify_cronbell(context):
    import requests
    requests.get("https://pulsecheck-shivam.fly.dev/ping/<token>", timeout=5)

task = PythonOperator(
    task_id="nightly_job",
    python_callable=run_job,
    on_success_callback=notify_cronbell,
)

Two settings that matter

Expected every — how often the job should run. Set it to the job's actual interval: hourly job → 3600 seconds.

Grace period — extra time before an alert fires, on top of the expected interval. This is your buffer for "sometimes it runs 10 minutes late and that's fine." Generous grace = fewer false alarms; tight grace = faster warnings.

Not sure which tool to use?

Prometheus / Grafana

Every account has its own scrape endpoint at /metrics/<your-token> — grab the exact URL from account settings and treat it like a password. It exposes:

• cronbell_monitor_up — 1 or 0, per monitor
• cronbell_monitor_last_ping_timestamp_seconds — unix timestamp of the last ping
• cronbell_monitor_seconds_since_last_ping — how long it's been quiet
• cronbell_monitor_period_seconds — the expected interval, for context
• cronbell_monitors_total{status="..."} — counts by status

Point an existing Prometheus at it and every monitor shows up next to everything else you already watch.

Public status pages

Every account has one shareable status page at /status/<your-token> (find your exact URL on account settings). It's opt-in per monitor — toggle "show on my public status page" on a monitor's edit page, and only that monitor's name, status, and uptime show up there. Nothing else on the page, no login, no ping URLs, no notes.

Slack, Discord, and generic webhooks

Email fires on every down alert by default. Add a Slack and/or Discord incoming webhook URL — or a generic one that gets a plain JSON POST for piping into your own systems — on your account settings page, and the same alert goes there too. There's a "send test" button for each, so you can confirm it's wired up correctly without waiting for a real outage.

FAQ

My job fails partway through — will I get an alert?
Yes, as long as the ping is the last line of the script. No ping means Cronbell assumes it didn't finish.

My job legitimately runs long sometimes — will that trigger false alarms?
Not if the grace period covers it. Set grace generously for a job with variable runtime.

Do I need to install anything?
No. A ping is one HTTP request — curl, wget, or any HTTP client works.

What's next

• "Start" and "fail" ping variants, to catch partial runs, not just missed ones
• Team accounts and an API for programmatic monitor management