Acquiring signal▌
Vercel won't tell you when a cron silently fails — or never fires at all. LastRun expects a ping every time your job runs and alerts you the moment one goes missing.
5 monitors free · no credit card · zero-migration
$ curl -fsS https://ping.lastrun.dev/p/<token> # last line of your job — that's the whole integration
Searched at 3am
Exhibit A — Vercel docs, “Cron Jobs”
“Cron invocations can be occasionally missed … or duplicated.”
Their words, not ours. A missed invocation creates no log at all — there is nothing to alert on. Unless something outside the platform was expecting that run.
That something is LastRun.
01How it works
Step 1 / Declare
Name the job, set the cron expression or interval it's supposed to follow — in any timezone, DST handled — plus a grace period.
Step 2 / Ping
One request at the end of the job — curl, fetch, or thewithMonitor()wrapper. Body becomes searchable run output.
Step 3 / Sleep
No ping by schedule + grace? You get one alert — email, Slack, Discord, Telegram, or webhook — and one recovery notice. Never a flood.
02Capabilities
Crashes throw errors. Absence doesn't. LastRun alerts on the run that never happened — the failure mode no log line, error tracker, or 5xx-rate alert can see.
Status, duration, and captured output for every run — paired start/finish pings compute real durations. Vercel keeps logs for a day; we keep your runs for 90.
✓ 05:00:02 · 1.24s · wrote 1,240 rows
✓ 05:00:01 · 1.19s · wrote 1,187 rows
✗ 05:00:04 · 0.31s · ETIMEDOUT s3.amazonaws.com
Vercel crons are UTC-only. LastRun schedules live in real timezones — DST transitions are unit-tested, not wished away.
0 5 * * * · Europe/Amsterdam
An outage opens a single incident: one down alert, one recovery alert. No 4am pager storm, no alert fatigue.
✗ down → ✓ recovered · 2 messages
The engine is an always-on process on separate infrastructure — never a Vercel cron monitoring Vercel crons — and is itself monitored externally.
heartbeat · 60s · independent
03Pricing
Pro
$9/month flat · or $90/year
Unlimited monitors · Slack, Discord & webhooks · 90-day history · duration trends
See full pricing04FAQ
No. LastRun monitors jobs you already run — it never executes or schedules them. Your job pings LastRun when it runs, and LastRun alerts you when an expected ping doesn't arrive on schedule.
It's the inverse. An uptime check pings your URL from outside to see if it answers. LastRun waits for your job to ping it when the job actually runs — so it catches the run that never happened, which an uptime check can't see. A reachable endpoint and a cron that silently didn't fire look nothing alike.
Error trackers catch jobs that crash. LastRun catches jobs that never run at all — a missed cron invocation produces no error and no log, so there's nothing for an error tracker to see. They're complementary, not competing.
No. Add one line of curl, wrap a route handler with withMonitor(), or run npx lastrun sync to create monitors from your vercel.json. No new runtime, no migration.
The monitoring engine is an always-on process on separate infrastructure — never a Vercel cron watching Vercel crons — and is itself monitored by an independent external service.
Yes. The SDK is Next.js-flavored, but the ping API is universal: any job that can send an HTTP request — GitHub Actions, Railway, Supabase, a server cron — can be monitored.
Yes. Invite teammates into a shared workspace with roles — owners and admins handle billing and members, members manage monitors and channels, and read-only viewers (useful for clients or stakeholders) can watch status without changing anything. On Pro you can also publish a no-login public status page per project with uptime and a 30-day incident history.
Free for 5 monitors with email alerts and 7-day history. Pro is a flat $9/month for unlimited monitors, all alert channels, 90-day history, and public status pages — no per-monitor fees.
More in the quickstart docs and on pricing.
Signup to first green check in under five minutes — we timed it.
Start monitoring — free