Django Cron Jobs — How to Set Up, Schedule & Monitor (2026)

Django doesn't have a built-in task scheduler. That's actually fine -- the ecosystem has solid options: management commands run via system cron, django-crontab, Celery Beat, or APScheduler. What Django also doesn't have is monitoring. Your scheduled tasks fail silently, and you find out when users complain or data goes stale.

This guide covers everything: what Django cron jobs are, how to set them up with each scheduling approach, why they fail silently, and how to add heartbeat monitoring so you get alerted the moment something stops working.

This guide covers Django 4.x and 5.x with Python 3.9+. Celery examples use Celery 5.x.

What Are Django Cron Jobs?

Django itself has no scheduler. When people say "Django cron jobs," they mean one of four things:

Management commands + system crontab -- The most common approach. You write a Django management command (a Python class in app/management/commands/) and schedule it with your system's cron daemon. This is the simplest option and works everywhere.
django-crontab -- A third-party package that lets you define cron schedules in settings.py and manages the crontab entries for you. Good if you want to keep scheduling config inside Django.
Celery Beat -- Part of the Celery distributed task queue. Celery Beat acts as a scheduler that dispatches tasks to Celery workers on a defined schedule. Best for apps that already use Celery for async task processing.
APScheduler -- A lightweight in-process scheduler. Runs inside your Django process, so there's no separate cron daemon involved. Common in smaller projects or single-server deployments.

Each approach has tradeoffs, but they all share the same problem: none of them tell you when a scheduled task fails or stops running entirely.

Why Django Cron Jobs Fail Silently

Django's management command system has no built-in failure notification. When you run python manage.py some_command via cron, here's what happens on failure:

If the command raises an exception, cron captures the stderr output. By default, cron emails it to the local system user -- which almost nobody reads on production servers.
If the cron daemon itself stops (server reboot, systemd misconfiguration, Docker container restart), the command simply never runs. There is nothing to raise an error because nothing is executing.
If the virtualenv isn't activated or DJANGO_SETTINGS_MODULE isn't set, the command fails with an import error that gets silently swallowed by cron's default output handling.
If the command hangs (database lock, network timeout, infinite loop), it never completes and never errors out. It just sits there consuming resources.

Most developers add try/except error handling:

class Command(BaseCommand):
    def handle(self, *args, **options):
        try:
            self.run_backup()
        except Exception as e:
            logger.error(f"Backup failed: {e}")
            # Maybe send an email

This catches crashes, but not silent failures. If your cron daemon dies, the script never runs, no exception gets raised, no email gets sent. You've only solved half the problem.

How to Set Up Cron Jobs in Django

Before we get to monitoring, here's how each scheduling approach works. If you already have your tasks set up, skip to the monitoring section.

Approach 1: Management Command + System Crontab

Create a management command:

# myapp/management/commands/backup_database.py

from django.core.management.base import BaseCommand
from django.conf import settings
import subprocess

class Command(BaseCommand):
    help = 'Backs up the database to S3'

    def handle(self, *args, **options):
        db = settings.DATABASES['default']
        filename = f"/tmp/backup-{db['NAME']}.sql"

        # Dump the database
        subprocess.run([
            'pg_dump',
            '-h', db['HOST'],
            '-U', db['USER'],
            '-d', db['NAME'],
            '-f', filename,
        ], check=True, env={
            **dict(__import__('os').environ),
            'PGPASSWORD': db['PASSWORD'],
        })

        # Upload to S3
        import boto3
        s3 = boto3.client('s3')
        s3.upload_file(filename, 'my-backups', f'db/{filename.split("/")[-1]}')

        self.stdout.write(self.style.SUCCESS('Backup completed'))

Then add the crontab entry:

# Edit crontab with: crontab -e
0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database

Important: Always use the full path to your virtualenv's Python binary. Don't rely on source venv/bin/activate in crontab -- it's unreliable. Also set DJANGO_SETTINGS_MODULE if your project needs it:

0 2 * * * cd /path/to/project && DJANGO_SETTINGS_MODULE=myproject.settings.production /path/to/venv/bin/python manage.py backup_database

Approach 2: django-crontab

Install django-crontab and add your schedules in settings.py:

# Install: pip install django-crontab
# Add to INSTALLED_APPS: 'django_crontab'

# settings.py
CRONJOBS = [
    ('0 2 * * *', 'myapp.cron.backup_database'),
    ('*/30 * * * *', 'myapp.cron.sync_inventory'),
    ('0 9 * * 1', 'myapp.cron.generate_weekly_report'),
]

# myapp/cron.py

def backup_database():
    """Runs nightly at 2 AM."""
    from myapp.services import BackupService
    BackupService.run()

def sync_inventory():
    """Runs every 30 minutes."""
    from myapp.services import InventorySync
    InventorySync.run()

Deploy the crontab entries with:

python manage.py crontab add     # Install cron jobs
python manage.py crontab show    # List active cron jobs
python manage.py crontab remove  # Remove all cron jobs

Approach 3: Celery Beat

For apps that already use Celery, Celery Beat provides schedule management:

# celery.py
from celery import Celery
from celery.schedules import crontab

app = Celery('myproject')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

app.conf.beat_schedule = {
    'backup-database-nightly': {
        'task': 'myapp.tasks.backup_database',
        'schedule': crontab(hour=2, minute=0),
    },
    'sync-inventory-every-30min': {
        'task': 'myapp.tasks.sync_inventory',
        'schedule': crontab(minute='*/30'),
    },
}

# myapp/tasks.py
from celery import shared_task

@shared_task
def backup_database():
    from myapp.services import BackupService
    BackupService.run()

@shared_task
def sync_inventory():
    from myapp.services import InventorySync
    InventorySync.run()

Run the Beat scheduler and a worker:

celery -A myproject beat --loglevel=info
celery -A myproject worker --loglevel=info

The Solution: Heartbeat Monitoring

Flip the approach: instead of alerting on failure, alert on the absence of success.

After your task completes successfully, ping an external URL. If that ping doesn't arrive on schedule, you get an alert. This catches every failure mode: crashes, network issues, server reboots, misconfigured cron, OOM kills, virtualenv not found, DJANGO_SETTINGS_MODULE not set -- all of it.

Here's how to set it up with CronSignal for each Django scheduling approach.

Monitoring Management Commands With CronSignal

The most common Django scheduling pattern is management commands run via system cron. There are two ways to add monitoring: inside the Python code, or from the crontab itself.

Option A: Ping Inside the Management Command

# myapp/management/commands/backup_database.py

from django.core.management.base import BaseCommand
import requests

class Command(BaseCommand):
    help = 'Backs up the database'

    def handle(self, *args, **options):
        # Your task logic
        self.run_backup()

        # Ping CronSignal on success
        requests.get(
            'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
            timeout=5
        )

        self.stdout.write(self.style.SUCCESS('Backup completed'))

    def run_backup(self):
        # Backup logic here
        pass

If run_backup() raises an exception, the ping never fires. Simple and effective.

If you don't want to add the requests dependency, use Python's standard library:

from urllib.request import urlopen

# At the end of your handle() method:
urlopen('https://api.cronsignal.io/ping/YOUR_CHECK_ID', timeout=5)

Option B: Pipe From Crontab With Curl

If you don't want to modify your management command code, ping from crontab using curl:

# Ping only on success (exit code 0):
0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database && curl -fsS --retry 3 https://api.cronsignal.io/ping/YOUR_CHECK_ID

The && operator ensures curl only runs if the management command exits successfully. The -fsS flags make curl fail silently on HTTP errors, show errors on network failures, and suppress the progress bar.

To send command output to CronSignal for debugging, pipe it:

# Capture output and send it with the ping:
0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database 2>&1 | curl -fsS --retry 3 -X POST --data-binary @- https://api.cronsignal.io/ping/YOUR_CHECK_ID

This sends both stdout and stderr as the POST body. When something goes wrong, you can see the command's output directly in CronSignal's dashboard without SSH-ing into the server.

Reusable Decorator for Multiple Commands

If you have many management commands to monitor, create a reusable decorator:

# myapp/utils/monitoring.py

import functools
import requests

def monitored_command(check_id):
    """Ping CronSignal after successful command execution."""
    def decorator(handle_func):
        @functools.wraps(handle_func)
        def wrapper(self, *args, **options):
            result = handle_func(self, *args, **options)
            requests.get(
                f'https://api.cronsignal.io/ping/{check_id}',
                timeout=5
            )
            return result
        return wrapper
    return decorator

Then use it in your commands:

from myapp.utils.monitoring import monitored_command
from django.core.management.base import BaseCommand

class Command(BaseCommand):
    help = 'Generates weekly reports'

    @monitored_command('YOUR_CHECK_ID')
    def handle(self, *args, **options):
        generate_reports()
        self.stdout.write('Reports generated')

Context Manager Approach

If you prefer context managers:

# myapp/utils/monitoring.py

from contextlib import contextmanager
import requests

@contextmanager
def monitor_task(check_id):
    """Context manager that pings on successful completion."""
    try:
        yield
    except Exception:
        raise
    else:
        requests.get(
            f'https://api.cronsignal.io/ping/{check_id}',
            timeout=5
        )

Usage:

class Command(BaseCommand):
    def handle(self, *args, **options):
        with monitor_task('YOUR_CHECK_ID'):
            self.run_sync()

Monitor your Django cron jobs for free

Get alerted the moment a job misses its schedule. Takes 30 seconds to set up.

Monitoring Celery Beat Tasks

If you're using Celery for scheduling, add the ping as the last step in your task function:

# myapp/tasks.py

from celery import shared_task
import requests

@shared_task
def process_orders():
    # Your task logic
    OrderProcessor.run()

    # Ping CronSignal on success
    requests.get(
        'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
        timeout=5
    )

The monitoring happens inside the task, not in the Beat schedule configuration. If the task raises an exception before reaching the ping, CronSignal detects the missed heartbeat and alerts you.

For existing tasks you don't want to modify, use Celery signals:

# myapp/signals.py

from celery.signals import task_success
import requests

MONITORED_TASKS = {
    'myapp.tasks.process_orders': 'CHECK_ID_1',
    'myapp.tasks.sync_inventory': 'CHECK_ID_2',
}

@task_success.connect
def ping_on_success(sender=None, **kwargs):
    task_name = sender.name if sender else None
    check_id = MONITORED_TASKS.get(task_name)
    if check_id:
        try:
            requests.get(
                f'https://api.cronsignal.io/ping/{check_id}',
                timeout=5
            )
        except requests.RequestException:
            pass  # Don't let monitoring failures break your tasks

Celery Beat Configuration

Your Beat schedule stays the same -- no changes needed:

# celery.py

app.conf.beat_schedule = {
    'process-orders-every-hour': {
        'task': 'myapp.tasks.process_orders',
        'schedule': crontab(minute=0),
    },
}

Monitoring django-crontab Jobs

If you're using django-crontab, add the ping inside the cron function:

# settings.py

CRONJOBS = [
    ('0 2 * * *', 'myapp.cron.backup_database'),
]

# myapp/cron.py

import requests

def backup_database():
    # Your backup logic
    run_backup()

    # Ping CronSignal on success
    requests.get(
        'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
        timeout=5
    )

Since django-crontab manages the crontab entries for you, the curl pipe approach is less practical here. Adding the ping inside your Python function is the cleanest option.

Monitoring APScheduler Jobs

If you're using APScheduler (common in smaller Django projects), add the ping inside the scheduled function:

# In your Django app's apps.py ready() method
# WARNING: Don't put this in settings.py or models.py
# It will run on every manage.py command (migrate, shell, etc.)

import os
from apscheduler.schedulers.background import BackgroundScheduler
import requests

def sync_inventory():
    # Your task logic
    InventorySync.run()

    # Ping CronSignal on success
    requests.get(
        'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
        timeout=5
    )

def start_scheduler():
    scheduler = BackgroundScheduler()
    scheduler.add_job(sync_inventory, 'cron', hour=2)
    scheduler.start()

# In apps.py:
# class MyAppConfig(AppConfig):
#     def ready(self):
#         if os.environ.get('RUN_MAIN'):  # Prevent double-start in dev
#             start_scheduler()

Note: Django-Q and Huey are also popular task queue options. The monitoring pattern is the same: ping after successful task completion.

Capturing Output for Debugging

When a task fails, knowing why it failed saves time. CronSignal can store the output of your management commands so you can view it in the dashboard.

From Crontab (Recommended)

Pipe the command's stdout and stderr to CronSignal as a POST body:

0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database 2>&1 | curl -fsS --retry 3 -X POST --data-binary @- https://api.cronsignal.io/ping/YOUR_CHECK_ID

This captures everything the management command prints, including Django's own error output, and sends it to CronSignal regardless of whether the command succeeded or failed.

From Inside Python

Send output programmatically with a POST request:

import io
import requests
from django.core.management.base import BaseCommand

class Command(BaseCommand):
    def handle(self, *args, **options):
        output = io.StringIO()

        try:
            result = self.run_backup()
            output.write(f"Backup completed: {result['rows']} rows exported\n")
            output.write(f"File size: {result['size_mb']}MB\n")
        except Exception as e:
            output.write(f"FAILED: {e}\n")
            raise
        finally:
            # Always send output, even on failure
            requests.post(
                'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
                data=output.getvalue(),
                timeout=5
            )

Handling Long-Running Tasks

For tasks that take significant time (ETL jobs, large data exports, ML model training), you want to know if they start but never finish. Ping at both start and end:

class Command(BaseCommand):
    def handle(self, *args, **options):
        # Ping start
        requests.get(
            'https://api.cronsignal.io/ping/YOUR_CHECK_ID/start',
            timeout=5
        )

        # Long-running task
        self.run_etl_pipeline()

        # Ping completion
        requests.get(
            'https://api.cronsignal.io/ping/YOUR_CHECK_ID',
            timeout=5
        )

If CronSignal gets a start ping but no completion ping within the expected runtime, you know the task is hanging or crashed mid-execution.

Common Issues With Django Cron Jobs

These are the issues we see most often when helping developers debug their Django scheduled tasks.

Virtualenv Not Activated in Crontab

The number one cause of silent cron failures. Crontab runs commands in a minimal shell environment -- your virtualenv isn't active, so Python can't find Django or any of your installed packages.

Wrong:

0 2 * * * cd /path/to/project && python manage.py backup_database

Right:

0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database

Always use the absolute path to the Python binary inside your virtualenv.

DJANGO_SETTINGS_MODULE Not Set

If your project uses separate settings files for development and production (e.g., settings.dev and settings.production), cron won't know which one to use:

# Set it explicitly in crontab:
0 2 * * * cd /path/to/project && DJANGO_SETTINGS_MODULE=myproject.settings.production /path/to/venv/bin/python manage.py backup_database

# Or set it in your manage.py:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings.production')

Database Connection Timeouts

Long-running management commands can hit database connection timeouts, especially if your database server closes idle connections. Add connection handling:

from django.db import connection

class Command(BaseCommand):
    def handle(self, *args, **options):
        # Close stale connections before starting
        connection.ensure_connection()

        # For very long tasks, close and reopen periodically:
        for batch in self.get_batches():
            self.process_batch(batch)
            connection.close()  # Forces reconnect on next query

PATH and Environment Variables Missing

Cron uses a minimal PATH (typically just /usr/bin:/bin). If your command calls system tools like pg_dump, redis-cli, or aws, they won't be found:

# Add PATH at the top of your crontab:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin

# Or use full paths to binaries in your management commands

Working Directory Issues

Always cd to the project directory first. Django needs to be in the project root to find manage.py and your apps:

# Always cd first:
0 2 * * * cd /path/to/project && /path/to/venv/bin/python manage.py backup_database

# Don't rely on absolute paths to manage.py -- it breaks relative imports:
# WRONG: 0 2 * * * /path/to/venv/bin/python /path/to/project/manage.py backup_database

Celery Beat Not Running

If you're using Celery Beat, the Beat scheduler process needs to be running for tasks to be dispatched. If it crashes and your process manager (systemd, supervisor) doesn't restart it, no tasks get scheduled. Monitor the Beat process itself with a simple heartbeat task:

# Add to your beat_schedule:
'celery-beat-heartbeat': {
    'task': 'myapp.tasks.heartbeat',
    'schedule': crontab(minute='*/5'),
}

# myapp/tasks.py
@shared_task
def heartbeat():
    requests.get('https://api.cronsignal.io/ping/BEAT_HEARTBEAT_ID', timeout=5)

Testing Your Setup

Verify monitoring works before relying on it.

Run your command manually:

python manage.py backup_database

Check CronSignal to confirm the ping arrived.

Then test failure detection. Add a deliberate error:

def handle(self, *args, **options):
    raise Exception("Test failure")
    # Ping never reached

Run the command. Verify no ping arrives and you get an alert within your configured grace period.

Getting Started

CronSignal handles the monitoring side for $5/month with unlimited checks. Create a check, grab your ping URL, add it to your Django tasks. Takes five minutes. Start with 3 checks free.

Whether you're using management commands, Celery, APScheduler, or django-crontab, the pattern is the same: ping on success, get alerted on absence.

For more on heartbeat monitoring and why it beats try/except error handling, see our guide on how to monitor cron jobs.

How to Monitor Django Cron Jobs (With Alerts)