work / case study 01 · runhooks
Scheduled webhooks, engineered never to fail silently.
Runhooks is the smartest way to run scheduled webhooks — cron, interval and one-off — with automatic retries, logs and alerts, so a failed task never goes unnoticed.
- Domain
- Developer tools
- Surfaces
- Web · REST API · CLI · MCP
- Architecture
- API-first · queues · pub/sub · auto-scaling workers
- Model
- Free-forever tier · paid plans
- Studio scope
- Product, UX, engineering, operations
| Job | Schedule | Target | Last run | Status |
|---|---|---|---|---|
| weekly-digest | 0 9 * * 1,4 | POST /hooks/digest | 142 ms | Succeeded |
| sync-inventory | every 15 min | POST /sync | Timeout | Retrying 2/3 |
| trial-reminder | once · Dec 25, 09:00 | POST /email/trial | — | Scheduled |
| billing-reconcile | 0 2 * * * | POST /billing/run | HTTP 500 | Failed · alert sent |
/ the brief
Cron is easy to start.
Hard to trust.
A crontab line on a server has no retries, no history and nobody watching. When a scheduled webhook fails overnight, the first to notice is often a customer.
The requirement: make every scheduled HTTP call a managed, observable job that fires on time at any scale — and make it equally easy to operate from a dashboard, a terminal, code, or an AI agent.
/ architecture
Thousands of parallel jobs.
Each one on time.
An API-first core, event-driven scheduling and a worker pool that scales with load — designed so precision holds when volume spikes.
/ independent benchmark
#2 of 10 schedulers for on-time execution.
An hourly, public latency benchmark measured how late each scheduler's request arrived after the top of the hour. Runhooks landed a median of 749 ms past the mark — ahead of AWS EventBridge, Google Cloud Scheduler and Cloudflare Workers.
“A solid, API-first managed service with response capture and retries.”
- 1 Posthook 656 ms
- 2 Runhooks 749 ms
- 3 QStash · Smpl Jobs ≈1.5 s
- — Google Cloud Scheduler · EasyCron · cron-job.org 4–8 s
- — AWS EventBridge ≈26.5 s
- — Cloudflare Workers ≈33 s
- — GitHub Actions ≈27 min
/ how the standard was applied
Six gates.
Each traced to a requirement.
Failure is a first-class state
Retry policies with exponential backoff, a recorded log for every execution, replay of any past run, and alerts by email, webhook or Slack.
One API, four surfaces
Web app, CLI and MCP server are all clients of the same documented REST API — and a second product, Statusloops, now runs on it too.
Scoped, rotatable keys
Prefixed live API keys that rotate on demand, with the MCP server running locally so credentials never pass through a third-party host.
Zero-friction onboarding
An AI agent can provision an account and schedule its first job with no signup form; humans get a visual cron expression builder.
Useful tools as acquisition
A technical blog and two free tools — a cron expression builder and a cron visualizer — attract exactly the right developers and drive strong organic traffic.
Open source, published to npm
The CLI and MCP server live in public repositories and ship to npm as versioned packages, so developers can inspect exactly what they run.
/ built for agents
Operable by AI agents through an open-source MCP server.
Claude, Cursor and any MCP client can create and manage jobs, read run history, replay failures and configure alerts — using the same contracts as every other client.
{
"mcpServers": {
"runhooks": {
"command": "npx",
"args": ["-y", "@runhooks/mcp"]
}
}
}/ outcomes