---
title: "Celery beat monitoring with a 10-second canary | Logdash"
description: "A canary task beat sends every 10 seconds, a push monitor that alerts on the first 15-second gap, and where Cronitor or Flower is the better pick."
url: https://logdash.io/cron-monitoring/celery-beat
---

# Celery beat monitoring

Have beat send a canary task every 10 seconds that posts to a Logdash push monitor, and the first 15 seconds without a ping tells you beat, the broker or every worker has stopped.

Celery beat fails without raising anything. When the beat process dies, workers sit idle, the queue stays empty, Flower shows healthy workers, and the error tracker stays quiet because no task ran. You find out when a customer asks why the weekly report never arrived.

## Celery beat health check: a canary task

The cheapest proof that beat is scheduling and a worker is consuming is a task that does nothing except say so. Beat sends it every 10 seconds, a worker runs it, the task posts to Logdash. If beat, the broker or every worker goes down, the posts stop. The expires option matters after an outage: returning workers discard canaries older than 10 seconds instead of chewing through hundreds of stale ones before real work.

 tasks.py 

```python
from urllib.request import Request, urlopen

from celery import Celery

app = Celery("tasks", broker="redis://localhost:6379/0")

PING_URL = "https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234"

app.conf.beat_schedule = {
    "logdash-heartbeat": {
        "task": "tasks.heartbeat",
        "schedule": 10.0,
        # A canary that waited in the queue is stale. Drop it.
        "options": {"expires": 10},
    },
}


@app.task(ignore_result=True)
def heartbeat():
    urlopen(Request(PING_URL, data=b"", method="POST"), timeout=5)
```

Run beat as its own process with celery -A tasks beat. Celery's docs call the embedded -B flag not recommended for production, and only one beat may run per schedule or every task fires twice. With django-celery-beat the entry still works: the database scheduler copies beat\_schedule into its table on start.

## What the 15 seconds mean

Push monitors are a Pro feature. On Pro, Logdash looks for a ping every 15 seconds and marks the monitor down on the first window without one. There is no grace setting, which is why the canary runs every 10 seconds. It also means a worker pool stuck on long tasks for 15 seconds pages you. If that is the outage you want to hear about, keep the canary on the main queue. If it is noise, route it to its own queue with one dedicated worker and accept that you then watch beat and the broker, not the main pool.

## Celery periodic task monitoring for nightly jobs

The canary proves the machinery runs. It does not prove the 3am invoice task succeeded, and a task that runs once a day cannot feed a monitor that wants a call every 15 seconds. For those, have the task set a Redis key with a 26-hour expiry when it finishes, serve a route that returns 503 once the key is gone, and point an ordinary HTTP monitor at it. Or use a tool built around schedules.

1. **Create a push monitor** Add a service on Pro, set the monitor to push and paste the id from its ping URL into PING\_URL.
2. **Deploy beat and a worker** Start celery -A tasks worker and celery -A tasks beat. The monitor turns up on the first check after the first canary.
3. **Kill beat** Connect a Telegram channel, then stop the beat process. Within 30 seconds a Telegram alert says the monitor is down with "Did not receive call for this time range". Start beat and the up message follows.

### Logdash vs Cronitor for Celery

| Feature                      | Logdash                                 | Cronitor                                             |
| ---------------------------- | --------------------------------------- | ---------------------------------------------------- |
| Setup                        | One canary task and a push monitor      | cronitor.celery.initialize discovers every beat task |
| Per-task schedules           | One canary for the whole system         | A monitor per periodic task, schedule read from beat |
| Time to alert when beat dies | 15 to 30 seconds                        | When the next scheduled task is late                 |
| django-celery-beat           | Works, the canary is a normal entry     | Auto-discovery does not support it yet               |
| Free plan                    | Push monitors start at Pro, $15 a month | 5 monitors                                           |

### When Cronitor is the better pick

- You have a dozen periodic tasks on different schedules and want each one watched with its own late alert.
- Your important tasks run hourly or nightly. Cronitor knows the schedule; Logdash needs the canary plus a freshness route per task.
- You want job monitoring on a free plan, or alerts by email and Slack rather than Telegram and webhooks.
- You want to see that a task started, ran too long or failed, not only that the canary arrived.

### How do I add a Celery beat health check? 

Beat has no endpoint and is not a worker, so celery inspect ping never reaches it. The honest check is the effect beat should have: a canary task arriving on schedule. Send it every 10 seconds and alert when it stops.

### What is the best tool for Celery monitoring? 

Flower for a live view of workers and tasks, with Prometheus metrics if you already run Alertmanager. Cronitor for per-task schedules. Logdash for the canary, uptime checks on the app, and logs from the Python SDK in one place.

### Does Celery periodic task monitoring catch a task that ran but failed? 

Only if success is what pings. Ping at the end of the task, after the work, and an exception skips the ping. The canary above proves scheduling, not the outcome of your other tasks.

### Does Celery beat monitoring need a paid Logdash plan? 

Yes. Push monitors are Pro only, at $15 a month. The free plan covers HTTP monitors, so the freshness route for nightly tasks works there.

## Keep reading

[All cron monitoring guides](https://logdash.io/cron-monitoring): One guide per scheduler, each with the code that proves a job ran and the alert for when it did not.

[Sidekiq monitoring](https://logdash.io/cron-monitoring/sidekiq): The Sidekiq Web UI shows queues, retries and dead jobs while you look at it; to be told when Sidekiq stops processing, run a canary job every 5 seconds that pings a Logdash push monitor.

[BullMQ monitoring](https://logdash.io/cron-monitoring/bullmq): Use Bull Board or Taskforce.sh to see queues and jobs, and add a 10-second job scheduler that pings a Logdash push monitor so you are told when workers stop processing.

[Kubernetes CronJob monitoring](https://logdash.io/cron-monitoring/kubernetes-cronjob): Kubernetes records when each CronJob last succeeded in status.lastSuccessfulTime and never alerts on it, so either alert on that timestamp in Prometheus through kube-state-metrics, or run a small watcher that pings an external monitor every 10 seconds while it is fresh.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.