SchedulesCron-scheduled HTTP requests, no servers required
Scheduled Webhooks.
Online Cron Jobs Without the Crontab.
Hit any URL on a cron schedule — every 5 minutes, every night at 02:00, whenever you need. Custom methods, headers, and bodies. Success judged by status codes and response keywords, with a per-run execution history. No VM to patch, no CI workflow abused as a scheduler.
Cron syntax
5-field expressions plus macros like @hourly.
Any request
GET to DELETE, custom headers and body, 120s timeout.
Verified runs
Status codes plus keyword checks, 7-day history.
Why run cron jobs as a service?
Every backend eventually grows a list of “hit this URL every N minutes” jobs: warm a cache, poll an API that has no webhooks, kick off a nightly sync, ping a free-tier host so it does not spin down. The work itself is trivial — one HTTP request — but the infrastructure around it never is. A crontab needs a server that stays up. A GitHub Actions schedule needs a repo, a workflow file, and tolerance for delayed runs. A cloud scheduler needs IAM, a function, and a deploy pipeline.
Hooklistener Schedules strips that down to the essentials. You define a cron expression, the request to send, and what a successful response looks like. Hooklistener runs it, records every execution, and shows you a history you can actually read. The schedule lives next to the webhook testing and monitoring tools you already use, so the whole request lifecycle — send, capture, verify, alert — sits in one place.
To be clear about what this is: Schedules sends HTTP requests on a timer. It does not execute your code — the work happens in whatever endpoint you point it at. That constraint is also the appeal: if your job is reachable over HTTP, you need zero new infrastructure to run it on a schedule.
A webhook scheduler built for real jobs
Not just “ping a URL.” Full control over the request, honest verification of the response, and a history you can debug from.
Standard cron expressions
Use the 5-field cron syntax you already know, or macros like @hourly and @daily. The UI shows a human-readable description of every expression, so a mistyped field is obvious before the first run.
Any method, headers, and body
GET, POST, PUT, PATCH, or DELETE with custom headers and a request body. Send bearer tokens, API keys, JSON payloads — whatever the target endpoint expects.
Real success criteria
Define success by expected status codes plus an optional response-body keyword check. An endpoint that returns 200 with an error message in the body can still be marked as a failed run.
7-day execution history
Every run is recorded for 7 days: status, HTTP status code, duration, and message. When a nightly sync misbehaves, you can see exactly which run failed and why.
Timeouts up to 120 seconds
Configure how long each request may take, up to 120 seconds. Toggle any schedule active or inactive without deleting it — useful for pausing jobs during maintenance windows.
API and MCP management
Manage schedules over the REST API or from an AI coding assistant via MCP tools. Create, update, and inspect executions without opening the dashboard.
How scheduled webhooks work
Open Schedules in the app
Schedules live in the Hooklistener sidebar. Create a new schedule and give it a name you will recognize in the execution history later.
Set the cron expression
Enter a standard 5-field expression or a macro like @hourly. The UI renders it back in plain English — “Every 5 minutes” — so you can confirm it before saving.
Configure the request
Set the target URL, method, headers, and body, plus a timeout of up to 120 seconds. Anything you can send with curl, you can send on a schedule.
Define success and ship it
Pick the status codes that count as success and optionally require a keyword in the response body. Toggle the schedule active, then watch runs land in the 7-day history.
// Cron expressions you might use
*/5 * * * * — every 5 minutes (cache warming, keep-alive)
0 2 * * * — at 02:00 every day (nightly data sync)
0 9 * * 1 — Mondays at 09:00 (weekly report)
@hourly — once an hour, on the hour
What developers schedule
If it can be triggered by an HTTP request, it can run on a cron schedule. These are the patterns we see most.
Cache warming
Hit your heaviest pages or API routes every few minutes so real users never pay the cold-cache penalty. A GET request on a */5 schedule is all it takes.
Polling APIs that lack webhooks
Not every service pushes events. Schedule a request against their API on an interval and turn a poll-only integration into something close to event-driven.
Nightly data syncs
Trigger your ETL or sync endpoint at 02:00 every night with a POST and a JSON body. Check the execution history in the morning instead of grepping server logs.
Report generation
Kick off weekly report builds with @weekly or a custom expression. The keyword check confirms the response actually says the report was queued.
Keep-alive pings
Free-tier hosts and serverless containers spin down when idle. A scheduled GET every few minutes keeps them warm without a janky CI workflow.
Triggering CI and deploy hooks
Most CI systems and static hosts expose a build hook URL. Schedule a POST to rebuild your site nightly or redeploy on a fixed cadence.
Hosted schedules vs. running your own cron
The DIY options all work — teams run them in production every day. The question is how much infrastructure you want to own for a job that boils down to one HTTP request.
Crontab on a VM
Maximum control and no per-run limits — if you already operate the server. The catch is that you now own uptime, patching, and the failure modes nobody monitors: the crontab that silently stopped after a reboot, the job that fails for a week before anyone checks /var/log/syslog. Execution history and alerting are things you build yourself.
GitHub Actions schedule
Free for public repos and versioned with your code, which is genuinely nice. But scheduled workflows are best-effort: runs are routinely delayed during peak load, schedules are disabled after 60 days of repository inactivity, and you are booting an entire runner VM to send a single request. Fine for a nightly job that can drift; wrong tool for “every 5 minutes, reliably.”
Cloud function + scheduler
Cloud Scheduler, EventBridge, and friends are reliable and scale well. The cost is moving parts: a function to deploy, IAM to configure, and observability scattered across two or three consoles when a run fails. For a fleet of jobs managed as infrastructure-as-code, it is a solid choice. For “call this URL hourly,” it is a lot of ceremony.
Where Hooklistener fits — and where it does not
Schedules gives you cron expressions, full request customization, success verification, and a 7-day execution history with zero infrastructure. If your job runs longer than 120 seconds, needs access to a private network the public internet cannot reach, or you manage hundreds of jobs as code, a DIY setup is the better fit. For everything else — the 90% of cron jobs that are really just HTTP calls — a hosted scheduler removes an entire category of maintenance.
Close the loop: capture, verify, monitor
Debug what your schedule actually sends. Before pointing a schedule at production, point it at a Hooklistener endpoint like https://my-project.hook.events/nightly-sync. Every scheduled request is captured with full headers, body, and timing, so you can verify the auth header and payload shape in the webhook debugger before the job touches real data. The webhook tester covers the one-off version of the same workflow.
Monitor the inverse direction.Schedules push requests out on a timer; uptime monitors check inward that your services respond. Hooklistener's monitors run configurable checks against any URL, alert via Slack, Discord, or email, and publish a shareable public status page. Our guide on cron job monitoring walks through combining the two so a silent failure never goes a week unnoticed.
Automate the management. Schedules are manageable via the REST API (/api/schedules, /api/schedules/:id/executions) and via MCP tools, so your AI coding assistant can create a schedule and check last night's runs without leaving the editor. See the changelog for what shipped recently.
Frequently asked questions
What cron syntax does Hooklistener support?
Standard 5-field cron expressions (minute, hour, day of month, month, day of week) plus macros like @hourly, @daily, and @weekly. The UI shows a human-readable description of each expression so you can verify it before the schedule runs.
What is the maximum timeout for a scheduled request?
Timeouts are configurable up to 120 seconds per request. If your job needs longer than that, have the scheduled request enqueue the work and return immediately, then track completion separately.
Can I customize the HTTP method, headers, and body?
Yes. Schedules support GET, POST, PUT, PATCH, and DELETE with custom headers and a custom request body — enough to call authenticated APIs, send JSON payloads, or trigger build hooks.
How long is execution history retained?
Each run is retained for 7 days with its status, HTTP status code, duration, and message. You can also fetch executions programmatically via the REST API at /api/schedules/:id/executions.
How are failures detected?
A run succeeds when the response matches your expected status codes and, if configured, contains the required keyword in the response body. Anything else — wrong status, missing keyword, timeout — is recorded as a failure in the execution history.
Can I manage schedules without the dashboard?
Yes. Schedules are fully manageable via the REST API (/api/schedules and /api/schedules/:id/executions) and via MCP tools, so AI coding assistants like Claude Code or Cursor can create and inspect schedules for you.
Are schedules available on the free plan?
Schedules are available on paid plans. See the pricing page for current plan details — the free plan still covers webhook capture, inspection, and replay.
Schedules are part of Hooklistener's paid plans — compare what each plan includes on the pricing page.
Put your first cron job online
Write a cron expression, point it at a URL, and let Hooklistener handle the rest — execution, verification, and history. No server, no crontab, no CI workaround.