DEV Community: Pytheas

I built an MCP server that lets Claude debug failed cron jobs

Pytheas — Tue, 14 Apr 2026 09:13:41 +0000

I built CronSignal, a cron job monitoring service. Recently I added an MCP server so AI tools like Claude Code and Cursor can interact with it directly.

Here's what it does and why I think it's worth setting up.

The debugging loop it replaces

When a cron job fails, the usual flow is: open dashboard, see what's down, SSH into the server, read logs, figure out the problem, fix it. Lots of tab switching.

With the MCP server, you can do most of that from the terminal. Claude has access to your monitors and can pull diagnostics and job output on its own.

What it looks like in practice

The MCP server exposes a few tools: list_checks, create_check, diagnose_check, get_check_output, pause_check, resume_check.

Diagnosing a failure:

"The db-backup check is showing as down, what's going on?"

Claude calls diagnose_check and get_check_output, pulls the stderr from the last run:

pg_dump: error: connection to server failed: FATAL:
password authentication failed for user "backup_user"

It tells you the credentials are wrong without you having to SSH anywhere. CronSignal captures up to 100KB of stdout/stderr per run, so the error is usually right there.

Creating a monitor:

"Set up a monitor for a deploy script that runs every day at 2am"

Claude calls create_check and gives you the curl to add to your crontab. No dashboard needed.

Checking status:

"How are my cron jobs looking?"

Lists all monitors with current status. Faster than opening a browser tab.

Bulk operations:

"Pause the staging monitors, I'm doing a migration"

One sentence instead of clicking through each one.

The useful part: Claude sees your code AND the error

The thing that makes this better than just reading a dashboard is that Claude has context on both sides. It can see the error output from the failed job AND the code that produced it. So instead of just showing you "connection refused," it can tell you why — misconfigured env var, wrong port, whatever.

Setup

Install the MCP server:

npx cronsignal-mcp

Add to your Claude Code or Cursor config:

{
  "mcpServers": {
    "cronsignal": {
      "command": "npx",
      "args": ["-y", "cronsignal-mcp"],
      "env": {
        "CRONSIGNAL_API_KEY": "cs_live_..."
      }
    }
  }
}

API key is at cronsignal.io → Settings → API Keys.

What is CronSignal

If you haven't seen it — CronSignal monitors cron jobs using heartbeat pings. You add a curl after your command:

0 2 * * * /scripts/backup.sh && curl -fsS https://api.cronsignal.io/ping/YOUR_ID

If the ping doesn't arrive on time, you get alerted via email, Slack, Discord, Telegram, or webhook. Free tier has 3 monitors. Pro is $5/month for unlimited.

The MCP server is a layer on top — it gives AI tools access to the same API you'd normally use through the dashboard.

Your Cron Jobs Are Silently Failing. Here's How to Know in 30 Seconds.

Pytheas — Tue, 14 Apr 2026 09:00:58 +0000

"My database backup script broke 11 days before I found out. Credentials got rotated, pg_dump started erroring, and cron just kept running it on schedule like nothing was wrong. No email. No alert. Eleven days of no backups. I only found out because I needed to restore something."

Sound familiar? If you've run cron jobs in production, you've probably been here.

Cron doesn't know your job failed

This is the part that gets people. Cron's job is to start your command at the time you told it to. That's it. If the command exits 1, cron doesn't care. If it hangs forever, cron doesn't care. If the server reboots and the cron daemon doesn't come back up, nobody cares.

You find out when:

A customer asks why their data is stale
A queue fills up because the consumer job stopped
You manually check a dashboard and notice the last run was 9 days ago

The fix is one line

After your job completes successfully, ping an external URL. If the ping stops arriving, you get alerted. That's the whole idea.

# before
0 2 * * * /scripts/backup-db.sh

# after
0 2 * * * /scripts/backup-db.sh && curl -fsS https://cronsignal.io/ping/abc123

The && means the curl only fires if the script exits 0. Script fails? No ping. Script hangs? No ping. Server goes down? No ping. In all cases, you hear about it.

I built CronSignal for this because I wanted something stupid simple. You create a check, tell it how often to expect a ping, and add the curl. If the ping is late, it hits you on email, Slack, Discord, Telegram, or webhook. Setup is maybe 30 seconds.

3 monitors are free. If you need more, it's $5/month flat for unlimited. No per-monitor pricing nonsense.

GitHub Actions has its own version of this problem

If you use schedule triggers in GitHub Actions, you've probably noticed they're... unreliable. GitHub can delay scheduled runs by minutes or hours. If your repo goes 60 days without a push, GitHub silently disables the schedule entirely. No warning.

I made a GitHub Action for this:

name: Nightly Build
on:
  schedule:
    - cron: '0 2 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run build
      - run: npm test

      - name: Ping CronSignal
        if: success()
        uses: CronSignal/ping-action@v1
        with:
          check-id: ${{ secrets.CRONSIGNAL_CHECK_ID }}

If the workflow gets delayed, skipped, or disabled, you know about it the same day instead of weeks later.

Works with basically anything

The curl pattern works anywhere. Not just crontab:

systemd timers — ExecStartPost directive
Kubernetes CronJobs — final container step
Laravel — $schedule->command('...')->after(function() { Http::get('...'); })
Django/Celery — requests.get() at the end of your task
Node — fetch() call after your logic

The point is: don't monitor the scheduler. Monitor whether the job actually finished. Those are different things.

Anyway

If you're running cron jobs without monitoring, you're going to have a bad time eventually. The fix is one curl command and 30 seconds of setup.

CronSignal if you want to try it. Or use any heartbeat monitoring service — Healthchecks.io, Dead Man's Snitch, whatever. Just use something. The && curl pattern works the same regardless.