How it works

One HTTP ping.
Everything else is automatic.

Your cron job runs exactly as it always has. Tymo sits at the end — one curl, no agents, no SDKs. If the ping never arrives, your team hears about it before anyone else does.

Get started — it's freeRead the docs
20 checks freeNo card needed30-second setup

Jobs fail silently. You find out from customers.

These are the three things that go wrong before you even know there's a problem.

01

No exit code ≠ success

A script can exit 0 and still have done nothing useful. Timeouts, empty results, and partial writes all look like success from the outside.

02

Cron just stops running

Cron doesn't retry, doesn't alert, and doesn't log to anywhere you check. A misconfigured job can sit silently broken for weeks.

03

Server monitoring misses it

Uptime monitors check if a server responds. They don't check if your 2am backup actually ran. That's a completely different problem.

Schedules

Cron expressions and plain intervals

Use a full 5-field cron expression or a human-readable interval. Either way, Tymo calculates the next expected ping window exactly — including daylight-saving edge cases.

Grace periods— a job that starts at 02:00 rarely finishes at 02:00. Set a tolerance window (1 min to 24h) so transient slowdowns don't page your team at 3am.
# Interval schedule
scheduleType: interval
scheduleValue: "every 24h"
graceMinutes: 30
 
# Cron expression
scheduleType: cron
scheduleValue: "0 2 * * *"
graceMinutes: 60
Security

IP allowlisting and CIDR ranges

Lock each ping URL to specific source IPs or CIDR blocks. Even if a URL leaks, pings from unexpected addresses are rejected with a 403 before any state is updated.

Leave the list empty to accept pings from any IP — useful during development. Add restrictions before going to production.
# Accepted — matches allowlist
GET /p/abc123
from 10.0.1.5
→ 200 ok: true
 
# Rejected — not in allowlist
GET /p/abc123
from 93.184.216.34
→ 403 IP not allowed
Notifications

Down alerts and automatic recovery

When a check misses its window, Tymo fires an alert across your configured channels. When the job runs and pings again, a recovery notification is sent automatically — you never manually close an incident.

Email is live now.SMS and WhatsApp are in development — enable the toggle today and they'll fire automatically when they launch.
# Alert fired
⚠ inventory_sync missed
expected at 14:00, now 14:28
→ sent to ops@company.com
 
# Auto-cleared on recovery
✓ inventory_sync recovered
pinged at 14:31 (31m late)
→ recovery sent to ops@company.com
Observability

Full audit log for every ping

Every ping is recorded: successful, rejected by IP filter, rate-limited, or received while paused. You get the exact timestamp, source IP, and outcome — enough to reconstruct exactly what happened.

Useful for debugging transient failures, proving a job ran (or didn't) for compliance, and understanding patterns over time.
outcome timestamp ip
──────────────────────────────
success 02:00:14 UTC 10.0.1.5
success 02:00:11 UTC 10.0.1.5
success 02:00:09 UTC 10.0.1.5
rej_ip 02:00:07 UTC 93.184.x.x
success 02:00:03 UTC 10.0.1.5
Integration

Works with every language and platform.

GET or POST — both work. No authentication, no headers. If it can make an HTTP request, it can send a ping.

bash
python
node
github-actions
kubernetes
# Minimal — success ping only
0 2 * * * /scripts/backup.sh && curl https://api.tymo.site/p/abc123

# GET or POST — Tymo accepts either
0 2 * * * /scripts/backup.sh && curl -X POST https://api.tymo.site/p/abc123

# No auth headers, no request body — any HTTP client works
0 2 * * * /scripts/backup.sh && wget -q -O- https://api.tymo.site/p/abc123
Get started

Add one line. Know immediately when something breaks.

20 checks free forever. No credit card. Takes 30 seconds.

Create a free accountSee pricing