DEV Community: Joscha Schultze

How to let Claude, ChatGPT or Cursor manage your cron jobs

Joscha Schultze — Sun, 15 Nov 2026 12:00:49 +0000

Your AI assistant writes the backup script in a minute. Then you still have to schedule it somewhere, and you have to notice when it stops running.

With MCP (Model Context Protocol), the assistant can do that part too. It creates the cron job, sets up monitoring, and later tells you which runs failed and why. The schedule runs on the cron service, so the chat doesn't have to stay open.

I'll use Cronjob.de for the examples, because that's the service I run. Other hosted schedulers offer MCP servers as well, and the steps are similar.

What MCP changes

MCP lets an assistant call tools of an outside service. A cron service exposes tools such as create_job, create_heartbeat or list_failures. You describe what you want, the assistant picks the tool and fills in the details. Most clients ask you before a call that changes something.

The assistant doesn't need to know the exact syntax of the service, and you don't need to switch to a dashboard for small changes.

Connecting the assistant

The MCP address is https://www.cronjob.de/bridge.

Claude (web and desktop): add a custom connector under Settings → Connectors and paste the address.

Claude Code:

claude mcp add --transport http cronjob https://www.cronjob.de/bridge

Then run /mcp inside Claude Code to sign in.

ChatGPT: add a custom connector with the same address, where your plan offers custom connectors.

Cursor and other MCP clients: add it as a remote server, for example in mcp.json:

{
  "mcpServers": {
    "cronjob": { "url": "https://www.cronjob.de/bridge" }
  }
}

On first use a browser window opens. You sign in to your account and allow access (OAuth 2.1 with PKCE). No password or API key ends up in the assistant's configuration.

What you can ask

"Call https://example.com/cron.php every 15 minutes."
The assistant creates the job with that schedule and shows you what it saved.

"My backup runs at 3 am on my own server. Tell me if it doesn't."
This is a different case: the job runs elsewhere, so the service should watch for a signal instead of calling a URL. The assistant creates a heartbeat and gives you the line for your crontab:

0 3 * * *  /path/to/backup.sh; curl -fsS -m 10 --retry 3 https://runcheck.de/<your-id>/$? > /dev/null

The /$? at the end sends the exit code of the script. You get an alert when the backup fails, and also when it doesn't report at all.

"Check whether my export job runs to the end."
A 200 from the trigger only means the request was accepted. With an end signal, the script reports when its last step is done, and the assistant gives you the line to add at the end of the script.

"Which jobs failed yesterday, and why?"
The assistant reads the failures with their status codes and error messages and sums them up. For a quick morning check, that's often faster than opening the dashboard.

"Monitor my website and show it on my status page."
Uptime checks and status pages work the same way.

Things worth checking

Time zones. Cronjob.de stores times in German time (Europe/Berlin). The assistant converts "9 am in New York" for you, but ask it to read the result back in your own time zone. Daylight saving time starts and ends on different dates in the US and in Europe, so a converted time can be off by an hour for a few weeks a year.

Deleting. The delete tool is marked as destructive and needs the exact name of the job, so a vague "clean up my jobs" can't wipe the account by accident. Still, read what the assistant wants to delete before you confirm. The history of a deleted job is gone too.

Limits and logs. Access tokens last one hour, and refresh tokens rotate on every use. If a refresh token is used twice, the whole chain is revoked. There are at most 60 changing calls per hour, and every change is logged with time and tool. You can disconnect the assistant at any time in your account.

Test the alert once. Break the URL on purpose, wait for the alert, then fix it. An alert you've never seen arrive is an assumption.

Without an AI subscription

You don't need an assistant with MCP to skip the cron syntax. The account has its own assistant: paste the instructions from your host or plugin documentation, and it fills in address, method and schedule. That one is in the free plan as well.

Who can use it

The MCP connection is part of the Unlimited plan and of the 14-day trial every new account starts with. Setup details and the full list of tools are on Manage cron jobs with AI.

I run Cronjob.de, so keep that in mind when reading the setup part.

Why cron jobs fail: what 12 days of real scheduled calls show

Joscha Schultze — Fri, 06 Nov 2026 15:42:37 +0000

How often does a cron job actually fail? And when it does, why?

I run a cron service that calls URLs on a schedule, so I can look at this from the outside for a lot of very different servers: shared hosting, WordPress sites, Laravel apps, small VPSs, serverless functions. For this post I analyzed every scheduled call from 4 to 15 October 2026, 12 days in total. Heartbeat pings and our own internal jobs are excluded, so this is purely "a scheduler calls your script over HTTP".

The short version: most cron jobs are boring, a few are broken all the time, and the rare failures of healthy jobs mostly fix themselves.

Most cron jobs never fail

79.9 % of cron jobs did not fail a single time in 12 days.
12.0 % failed on less than 1 % of their calls.
2.2 % failed on 1 to 50 % of their calls.
5.9 % failed on more than half of their calls, and 4.4 % failed on every single call.

So eight in ten jobs are completely fine, and almost all the rest have the occasional hiccup. If you look only at jobs that basically work (under 50 % failures), the failure rate is 0.3 % of calls, about three in a thousand.

The failures are concentrated in very few jobs

The 5 % of cron jobs with the most failures cause 99.7 % of all failures.

That changes how you should read any "failure rate". The average across all jobs looks scary, but it's dominated by jobs that are simply dead. If you include them, the rate jumps from 0.3 % to over 9 % of all calls. Those jobs aren't flaky, they're broken, and they keep running because nobody looks.

Dead jobs: mostly an address that no longer exists

Of the jobs that failed on more than half of their calls, 56 % got a 404.

The pattern is almost always the same: the site was rebuilt, moved to a new CMS, or a plugin was removed, and the cron job still points to the old file. Nothing crashes, the scheduler just gets "not found" forever.

What helps:

After a relaunch or migration, go through your cron jobs the same way you go through redirects.
Make sure a 404 actually reaches someone. A job that fails silently for months is the real problem, not the 404 itself.

Healthy jobs: the script itself is the most common cause

For jobs that normally work, these are the share of jobs that hit each error at least once in the 12 days:

Cause	Share of jobs	What usually happened
Error in the script (HTTP 500)	5.4 %	PHP error, memory limit, database briefly gone
Connection dropped	3.5 %	Server closed the connection midway, often under load or by a firewall
Server overloaded (HTTP 503)	2.7 %	Web server too busy or in maintenance
Empty reply	2.1 %	Connection open, but no answer; usually the host killed the process
Upstream without an answer (HTTP 502)	1.8 %	A proxy or CDN in front of the server got nothing usable
Connection refused	1.6 %	Nothing listening for a moment, e.g. during a restart
TLS/HTTPS failed	1.1 %	Often a certificate being replaced
Server unreachable	0.6 %	Network fault or server down

Two things stand out. First, the number one cause is your own code, not the network. A 500 on a cron endpoint is usually the same bug you'd see in the browser, just at 3 a.m. Second, a big part of the list is "the server was briefly not there": overload, restarts, killed processes, proxies in between.

Tip: let your cron endpoint print a short reason when it fails, e.g. http_response_code(500); echo "Import failed: supplier API timed out";. Whatever logs or alerts your scheduler gives you, a one-line reason is worth more than a bare status code.

Two thirds of failures happen once and then fix themselves

Of all failure phases, 67 % consisted of exactly one failed call. The next run worked again.

That's an argument for two things:

Don't alert on the first failure for frequent jobs. A job that runs every minute and fails once is usually noise. Alerting after two or three failures in a row cuts most false alarms without hiding real outages. For a job that runs once a night, alert on the first failure, because the next try is 24 hours away.
Retry, but only when it's safe. A refused connection, a DNS error or a failed TLS handshake means the request never reached your script, so a retry is harmless. A 502 or 503 usually means the same, but not always: a gateway can lose the response after your script has already committed its work. After a 500 or a timeout the script may have done half its work. Retrying an import or a payment run blindly can do it twice. For jobs like that, give each scheduled run its own ID, send the same ID with every retry, and let the script process each ID only once. If you can't do that, don't retry them automatically. (Updated after a helpful comment from lastmileops below.)

Time limits matter for the long tail

Half of all cron jobs finished within 4.4 seconds on average, and 13 % took less than a second. But 11 % ran longer than 30 seconds on average. Those are mostly imports, exports and backups.

For that group the time limit is the real risk. Shared hosts, PHP's max_execution_time, reverse proxies and schedulers all have one, and when you hit it the script stops halfway. Typical fixes:

Process in batches and remember where you stopped, so each call does a fixed amount of work.
Or trigger the work over HTTP and let it run in the background (a queue, fastcgi_finish_request(), a worker), then report the result with a heartbeat.

Bot protection quietly blocks some jobs

A small share of jobs (0.4 %) got a Cloudflare challenge page instead of their script. For those, every call failed, because a scheduler can't solve a JavaScript or CAPTCHA check. If your site sits behind a WAF or CDN, allow your scheduler explicitly, ideally by its User-Agent or a verified-bot setting rather than by IP, since IPs can change.

Free hosts are a special case: some answer every request without a browser with a 200 and a JavaScript cookie check. The scheduler sees "success", but the script never ran. If your job reports success and nothing happens, check what the response body actually contains.

What I take from this

Most cron failures are not mysterious. A dead URL, a crashing script, a host that was briefly busy.
The dangerous jobs are the silent ones. Almost all failures come from a few jobs that stay broken because nobody gets told.
Alert on patterns, not single blips, and retry only what's safe to retry.
Look at the response, not just the status code. Both for failures (why did it fail?) and for "successes" (did the script really run?).

The full numbers, method and FAQ are on our data page: Why cron jobs fail: statistics. If you want to dig into a specific problem, I also wrote guides on a cron job that isn't running and when to retry a failed cron job.

Method: all scheduled HTTP calls made by Cronjob.de between 4 and 15 October 2026, excluding heartbeat pings and our own jobs. "Failure" means an HTTP status of 400 or higher or a network error. Percentages only, rounded. I run Cronjob.de, so this is data from one service, not the whole internet.

Monitoring cron jobs with heartbeats: how to notice the job that silently stopped

Joscha Schultze — Fri, 30 Oct 2026 08:09:18 +0000

The worst cron failure is not the one that throws an error. It's the one that simply doesn't happen.

The backup that hasn't run since the server was migrated. The import that stopped when someone redeployed and the crontab wasn't part of the image. The cleanup script that hangs forever on a lock, so the next runs pile up behind it. Nothing crashes, no error mail goes out, and you find out weeks later when you actually need that backup.

I run a cron service, and "it stopped and nobody noticed" is by far the most common story I hear. The fix is a simple pattern called a heartbeat (also known as a dead man's switch).

The idea in one sentence

Your job sends a small "I'm done" signal to a URL every time it finishes, and a monitor alerts you when that signal doesn't arrive on time.

The important part is the direction. Classic monitoring asks "did something go wrong?". A heartbeat asks "did the thing that should have happened actually happen?". That catches every failure mode at once: the server is down, cron isn't running, the crontab is gone, the script crashed before it could report anything, the job hangs.

The simplest version

Say this is your nightly backup:

# crontab
30 2 * * * /usr/local/bin/backup.sh

Add one request at the end, and only when the script succeeded:

30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://example-monitor/your-check-id

&& means the ping is only sent if backup.sh exited with code 0. If the backup fails, no ping arrives and you get an alert.
-fsS keeps curl quiet but still shows real errors.
-m 10 stops curl after 10 seconds, so a slow monitoring endpoint can never block your job.
--retry 3 covers a short network hiccup, so you don't get a false alarm.

On the monitor side you set two things: the schedule (every day at 02:30) and a grace period (for example 30 minutes). If no ping arrives by 03:00, you get notified.

Report failures right away

With only &&, a failed run is noticed when the grace period is over. If your monitor supports it, report the exit code directly instead:

30 2 * * * /usr/local/bin/backup.sh; curl -fsS -m 10 --retry 3 https://example-monitor/your-check-id/$?

$? is the exit code of backup.sh. Many heartbeat tools accept it in the URL: 0 counts as success, anything else as an immediate failure. One line, both cases covered.

Catch jobs that hang

A job that never finishes is the sneakiest case: no success, no error, just a process sitting there. Send a signal when the job starts, too:

#!/bin/sh
URL=https://example-monitor/your-check-id

curl -fsS -m 10 --retry 3 "$URL/start" > /dev/null

/usr/local/bin/import.sh
STATUS=$?

curl -fsS -m 10 --retry 3 "$URL/$STATUS" > /dev/null
exit $STATUS

Now the monitor knows the job began. If neither success nor failure follows within the grace period, it can tell you the run is stuck. As a bonus you get the duration of every run, which is great for spotting a job that slowly gets slower.

Send the output along

When something fails, the first question is "what did it print?". If your monitor accepts a POST body, send the last lines of the log with the ping:

/usr/local/bin/import.sh > /tmp/import.log 2>&1
STATUS=$?
tail -c 10000 /tmp/import.log | curl -fsS -m 10 --retry 3 --data-binary @- "$URL/$STATUS"

Then the alert and the error message arrive together, and you don't have to SSH into the server to find out what happened.

Choosing the grace period

The grace period decides how fast you hear about problems versus how many false alarms you get.

Longer than the normal run time. If the job usually takes 20 minutes and sometimes 40, a 15 minute grace period will page you for nothing.
Shorter than "too late". If the export must be ready by 7:00 for the morning report, the alert has to come before that.
For frequent jobs, allow a missed run. A job every 5 minutes with a 10 minute grace period tolerates one slow or skipped run before alerting. That's usually what you want.

Pitfalls I see again and again

The ping breaks the job. If the monitoring service is unreachable and your script runs with set -e, a failing curl can fail the whole job. Keep the timeout short and add || true when the ping is inside the script and must never stop it.

Pinging at the start instead of the end. A single ping as the first line proves only that cron started the script. Put it at the end, or use the start/finish pair above.

Cron's minimal environment. Cron runs with a very small PATH. A job that works in your terminal can fail under cron because curl or your interpreter isn't found. Use absolute paths, e.g. /usr/bin/curl.

Time zones. The server's cron may run in UTC while you configured the monitor in local time, or the other way around. Then every alert comes an hour or two "late" and everyone learns to ignore them. Check both sides once.

Alerts that go nowhere. An alert to root@localhost or to the inbox of a colleague who left last year is the same as no alert. Send it to a channel people actually read, like a team mailbox, Slack or Teams, and test it once.

Overlapping runs. If a run takes longer than the interval, two copies can run at once. Wrap the job in flock -n /tmp/import.lock so a second copy exits immediately instead of piling up, and let the heartbeat tell you when runs get too long.

Tools

The pattern is simple enough to build yourself, but then you have to monitor your monitor. Some ready-made options:

Healthchecks.io: open source, you can use the hosted version or run it yourself.
Cronitor: commercial cron and job monitoring.
Cronjob.de: that's mine. Heartbeats with /start, /fail and the exit code in the URL as shown above, POST output up to 10 KB, alerts by e-mail, and on the Unlimited plan also via Slack, Teams, Discord, Telegram or webhook. The free plan includes one heartbeat with e-mail alerts, servers are in the EU.

Whichever you choose: set up one heartbeat for the job you'd be most embarrassed to find broken. For most of us that's the backup.

I run Cronjob.de, a cron service from Germany, so I'm obviously not neutral about the tools section. The pattern itself works with any of them.

How to run cron jobs without a server: 4 ways and when to use which

Joscha Schultze — Fri, 23 Oct 2026 09:03:07 +0000

Sooner or later almost every web project needs something to happen on a schedule: send the newsletter at 8, clean up old sessions every night, import a price feed every 15 minutes, run wp-cron.php reliably.

On a VPS you open crontab -e and you're done. But many projects don't have that: shared hosting without SSH, a serverless app, a static site with an API route, a WordPress or Shopware shop where the host doesn't offer cron.

I've been running a cron service for many years, so I see these setups every day. The most common question I get is still: “It works when I open the URL in my browser, so why does it fail on schedule?” Usually it’s a timeout, a login wall or a firewall blocking unknown IPs. Here are the four approaches that actually work, and where each one stops working.

The one question that decides it

Can your job be triggered by an HTTP request?

Yes. It's a PHP script, an API route, a webhook, wp-cron.php. Then you only need something that calls a URL on a schedule. That's options 1 to 3.
No. It's a Python script, a binary, a data pipeline that needs its own runtime. Then you need a platform that runs your code. That's option 4.

Most "I need a cron job" questions on shared hosting are the first kind, even if they don't look like it at first.

1. An online cron service (URL calls on a schedule)

You enter a URL and a schedule, the service calls it, logs the response and tells you when it fails.

Typical setup for a PHP job on shared hosting:

<?php
// cron/cleanup.php: protect it with a secret, it's a public URL
if (($_GET['key'] ?? '') !== getenv('CRON_KEY')) {
    http_response_code(403);
    exit;
}
// ... do the work ...
echo "deleted 42 sessions";

Then schedule https://example.com/cron/cleanup.php?key=… every hour.

Services: cron-job.org (free, run from Germany), EasyCron, Cronjob.de (that's mine: free tier and paid plans, servers in the EU).

Good for: shared hosting, WordPress (wp-cron.php), Laravel's schedule:run behind a route, any API endpoint.

Watch out for:

Timeouts. The service waits a limited time for your response (often 30 to 60 seconds). Long jobs should return quickly and keep working in the background, or be split into batches.
Security. The URL is public. Use a secret key or basic auth, and don't put real credentials in the query string if you can avoid it.
"200 OK" isn't "it worked". If your script catches an error and still prints a page, the call looks successful. Return a non-2xx status code on failure, or check the response body for an expected text. Some services can do that for you.

2. GitHub Actions on a schedule

If your code is on GitHub anyway, a workflow can run on a cron schedule:

# .github/workflows/nightly.yml
on:
  schedule:
    - cron: "17 3 * * *"   # 03:17 every day
      timezone: "Europe/Berlin"   # default is UTC
  workflow_dispatch:       # allows manual and external triggers

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python scripts/nightly.py

Good for: jobs that run your repository's code, a few times per day.

Watch out for:

It's not precise. GitHub says scheduled runs "can be delayed during periods of high loads", and under enough load queued jobs may be dropped. The shortest interval is 5 minutes.
Scheduled workflows are disabled in public repositories after 60 days without repository activity.
The default time zone is UTC. Add a timezone to the schedule (as above) if the job should follow local time.

If timing matters, a common trick is to keep the workflow_dispatch trigger and start the workflow from outside through the GitHub API on a reliable schedule.

3. Your cloud provider's scheduler

AWS EventBridge Scheduler, Google Cloud Scheduler and Azure Logic Apps all call an HTTP endpoint or a function on a cron schedule.

Good for: projects already running on that cloud, with IAM, retries and logging in one place.

Watch out for: setup effort (accounts, roles, billing) that is out of proportion if all you need is "call this URL every 10 minutes". Pricing is usually small but not always zero.

4. A platform that runs your code

Render, Railway, Fly.io, Kuberns and similar platforms have "cron job" services: you point them at a repository, give them a command and a schedule, and they start a container for each run.

Good for: jobs that are not an HTTP endpoint: Python scripts, workers, anything that needs its own runtime and more time.

Watch out for: cold starts, per-run costs, and that the job runs in a separate environment from your app, so it needs its own access to your database.

The part everyone forgets: knowing when a job didn't run

All four options answer "how do I start the job?". None of them, by default, answers "how do I notice when it silently stopped?"

The pattern for that is a heartbeat (also called a dead man's switch): at the end of each successful run, the job pings a URL. If the ping doesn't arrive in time, you get an alert.

# crontab on your own server
0 * * * * php import.php && curl -fsS https://runcheck.de/abc123

The && matters: the ping only goes out if the job exited successfully. This works for jobs on your own server, in GitHub Actions, n8n or anywhere else that can make an HTTP request.

Dedicated tools for this are Healthchecks.io, Cronitor and Dead Man's Snitch. Some cron services (including mine) combine both: they call your URLs and watch the heartbeats of jobs that run elsewhere, so everything scheduled is in one list.

Quick decision table

Your situation	Use
Shared hosting, PHP, WordPress, an API route	Online cron service (1)
Code lives on GitHub, timing can be loose	GitHub Actions (2)
Already deep in AWS/GCP/Azure	Cloud scheduler (3)
Not an HTTP endpoint, needs its own runtime	Code-running platform (4)
Jobs already run somewhere, but you don't trust them	Add heartbeat monitoring

Disclosure: I run Cronjob.de, one of the services mentioned in option 1. I've tried to describe all options as they are. If I got something wrong about another tool, tell me in the comments and I'll fix it.