Cron jobs fail quietly. Ping Clock makes the silence loud.

Q: What if your ping endpoint is down when my job runs?

Use retries in your ping command, like the `--retry` flag in the curl example. We keep the endpoint small and fast for this reason.

Your job pings a unique URL when it finishes. If the ping is late or never arrives, we alert you. That's the whole idea, and it catches the failures uptime checks never see.

Get 20 free checks

No card. Copy a snippet, paste it, done.

The failure nobody sees

Uptime monitors check things that answer requests. A nightly backup doesn't answer requests. Neither does the 2 a.m. invoice export, the certificate renewal script or the job that clears out temp files before the disk fills up.

When those stop, nothing turns red. The server is up. The website loads. Three weeks later someone needs the backup, and the newest file is from the 4th.

Ping Clock flips it around. Instead of us checking your job, your job checks in with us. No check-in, no peace and quiet.

How it works

Create a check. Give it a name and a schedule: "every 24 hours, 30 minutes grace", or a cron expression with a time zone.
Add one line to the job. Ping the check's URL when the job succeeds. Optional: ping /start when it begins and /fail when it breaks.
Get told when it goes quiet. If a ping is late past the grace time, the check goes down and alerts fire. When pings resume, you get a recovery message.

Paste and go

Example URLs only. Your dashboard shows the real one for each check.

Bash / crontab

0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 5 https://www.pingclock.com/ping/YOUR-CHECK-ID

Python

import urllib.request
# ... your job ...
urllib.request.urlopen("https://www.pingclock.com/ping/YOUR-CHECK-ID", timeout=10)

Node.js

// ... your job ...
await fetch("https://www.pingclock.com/ping/YOUR-CHECK-ID");

PowerShell

# ... your job ...
Invoke-RestMethod https://www.pingclock.com/ping/YOUR-CHECK-ID

Kubernetes CronJob

command: ["/bin/sh", "-c", "./run-job && wget -qO- https://www.pingclock.com/ping/YOUR-CHECK-ID"]

What's in the box

Period or cron schedules. Simple "every N hours" with grace time, or full cron syntax with any IANA time zone.
Start, success and fail signals. Know the difference between "didn't run", "ran and failed" and "started but never finished".
Exit codes. Ping /0 or /1 and so on, straight from $?.
Run duration. With start and success pings we record how long each run took (Pro and up).
Log tail. POST the last lines of output with the ping and see them next to the failure (Pro and up, size capped).
Email-in pings. A unique address per check for tools that can only send email.
Alerts. Email, Slack, Microsoft Teams, Discord and generic webhooks.
API. Create and manage checks from code (Pro and up).

FAQ

What if your ping endpoint is down when my job runs?

Use retries in your ping command, like the --retry flag in the curl example. We keep the endpoint small and fast for this reason.

Does a ping slow down my job?

It's one HTTP request at the end. Use a short timeout so a network hiccup never blocks the job.

Can I see why a job failed?

On Pro and Business, send the last lines of output in the POST body. They show up on the failed run.

What's the difference between period and cron schedules?

Period: "expect a ping every 6 hours." Cron: "expect a ping at 02:00 Europe/Berlin every weekday." Cron schedules handle irregular timings and daylight saving properly.

Do you support SMS alerts?

Not yet. Email, Slack, Teams, Discord and webhooks.

Is the free plan actually free?

Yes. 20 checks, email and Slack alerts, one user. No trial clock.

Does this replace uptime monitoring?

No, it complements it. Uptime checks watch things that respond. Heartbeats watch things that are supposed to run.