Something has to call your URL. On time. Forever.
Register a cron, an interval or a one-off. When it comes due, Scheduler sends exactly one signed HTTPS request to a URL you own — with retries, a dead-letter queue, a delivery log, and an email the moment it starts failing. We never run your code.
A schedule almost never fails loudly.
It fails the other way: the job stops, the dashboard still says green, and you find out a month later from someone else. Here are the three shapes that takes.
The line that is still there
Classic cron runs the command and moves on. It has no opinion about whether the command worked.
0 3 * * * /opt/backup.sh
# exit status: not checked, ever
backup-2026-07-21.tar.gz
→ newest file is 32 days old
The drift, then the stop
A repo-hosted scheduled workflow runs on shared queue capacity, so it lands minutes off its slot — and some hosts disable the schedule outright once the repo goes quiet.
run #418 09:27
run #419 09:31
run #420 09:24
→ the repo went quiet
→ the folk fix is a fake commit job
The mail that was never sent
Cron mails you the job's output. A job that exits 1 and writes nothing has no output — so there is nothing to mail, and half these boxes have no mail daemon anyway.
No mail for deploy.
the job exited 1 and wrote
nothing to stdout
Every one of these is the same failure twice: the thing didn't run, and nobody found out.
There are three answers to “I need a timer.” Two of them want your code.
You did not come here to adopt an SDK or to add a monitoring vendor on top of the cron box you already can't find. You came here because something has to call a URL you already built.
Scheduler is the third lane and only the third lane. It runs no user code, ever — that is the product's identity, not a gap in it. If you need replayable multi-step state, fan-out or human-in-the-loop steps, you want a workflow runtime and you should go and get one.
One request. Five things in it that matter.
This is the whole contract. Hover a note to light up the line it describes.
POST /jobs/nightly-sync HTTP/1.1Host: api.yours.comParsons-Signature: eyJhbGciOiJFUzI1NiJ9…Parsons-Idempotency-Key: proj_7f2a.sch_nightly_sync.3.1787331600000Parsons-Fire-Time: 1787331600000Content-Type: application/json {"window":"24h"}
Best-effort to within seconds of the slot — not to the millisecond, and never faster than one fire every 60 seconds.
Your endpoint can prove it was us.
The usual defence for a scheduled endpoint is a string you invented, pasted into two environments, and now have to rotate in both forever. Anyone who learns that string is you.
Two copies of one secret
→ it is in two sets of logs and one CI config
→ possession of the string is authority
One public URL, nothing to leak
"project": "proj_7f2a",
"schedule_id": "sch_nightly_sync",
"version": 3, "seq": 412,
"fire_time": 1787331600000,
"aud": "api.yours.com",
"exp": iat + 300 }
Civil time, and the morning after an outage.
Cron is resolved as civil time in the IANA zone you name. 0 9 * * MON-FRI in Australia/Sydney is 9am in Sydney in July and 9am in Sydney in January — you never do the arithmetic twice a year. We take five-field and six-field-with-seconds expressions, @daily, @hourly, and day names.
48 fires land on your endpoint the instant the gap ends. Your rate limiter, your database and your on-call all find out at the same moment.
One fire, then the next slot as normal. The 47 outlines are the slots we coalesced away. A gap costs you one run, not a thundering herd — and never a burst your rate limiter has to survive.
Two emails. Not four hundred.
Per-failure alerting dies the same way every time: the volume trains you to mute it, and once it is muted it is decoration. We page on the transition — once when a schedule starts failing, once when it recovers.
Emails the project owner. This is the default if you configure nothing at all — you do not have to opt in to being told.
POSTs the failure to a URL you own, through the same egress guard a target goes through. Public HTTPS only, checked again on the way out.
Files an issue in your own Parsons Tracker project over an internal binding — no API key, no token to store. Severity high on break, low on recovery. Off-platform trackers connect with a pik_ intake key.
Up to three failure actions per schedule. Intake keys are encrypted at rest and redacted to ‹set› on every read, through the console and through MCP alike.
How do you know the alarm works?
You find out when it matters, usually by discovering it didn't. So we shipped a fire drill. test_on_failure genuinely fires your configured actions once — a real email to your real address, a real POST to your webhook, a real issue in your tracker — with the subject marked [TEST].
It is a real delivery, because a fake one would prove nothing. It just doesn't lie to your history: the health state does not move and the runs log does not gain a row.
| 2026-08-22 03:00:00 | 200 |
| 2026-08-21 03:00:00 | 200 |
| 2026-08-20 03:00:01 | 200 |
The create form shows you the next five fires.
Type an expression and the console tells you, in English and in dates, exactly what you just asked for — before anything is armed. This is a working copy of it. Drive it.
| fired_at | attempts | status | http_status | lateness | dlq |
|---|---|---|---|---|---|
| 2026-08-21 09:00:00 | 1 | delivered | 200 | 0.4 s | — |
| 2026-08-20 09:00:00 | 1 | delivered | 200 | 1.1 s | — |
| 2026-08-19 09:00:00 | 2 | delivered | 200 | 0.8 s | — |
| 2026-08-18 09:00:00 | 4 | failed | 503 | 0.6 s | true |
| 2026-08-17 09:00:00 | 1 | delivered | 200 | 0.3 s | — |
The console also carries the fleet roll-up — armed, paused, failing, healthy, and a live next-fire countdown — plus a copy-ready JWKS block on every schedule's detail view. Every button in it calls the same functions the MCP tools call. There is no second-class surface.
Run the deploy script a hundred times. Still one schedule.
Give a schedule your own stable id and create_schedule converges instead of piling up. That is the whole infra-as-code story, and it is one argument.
$ deploy.sh → created sch_01H8… $ deploy.sh → created sch_01H9… $ deploy.sh → created sch_01HA… $ deploy.sh → created sch_01HB…
$ deploy.sh → created (version 1) $ deploy.sh → replaced (version 2) $ deploy.sh → replaced (version 3) $ deploy.sh → replaced (version 4)
The honest half: a create with an id you already used is a wholesale replace, not a patch. Fields you leave out go back to their defaults and the version bumps. Send the whole object every time — which is what a deploy script does anyway. Ids look like sch_[a-z0-9_], up to 64 characters, and they are yours to choose.
Eleven tools, no dashboard required.
Scheduler ships as MCP tools, so Claude, ChatGPT or Cursor can create, pause, test and audit your schedules directly. guide needs no auth at all — an agent can read the entire playbook, including the signed-request contract and the health-check 503 pattern, before it holds a token.
Here is exactly how much clock your account buys.
Everyone in this category makes you find their real constraint in the docs, or discover it at runtime. Ours is on the landing page. Runs are counted account-wide across every project you own, per 30-day month — 20,000 of them are included in the $15, and past that they simply draw from your prepaid credits at $17 per million. Nothing refuses a funded account until the 200,000-a-month abuse fuse.
Nothing stops halfway through a month. Runs past the included 20,000 are billed daily from your prepaid balance at $17 per million — roughly wholesale plus half, printed here rather than discovered on an invoice. A hard refusal exists in exactly two places: an account with no credits parks at the allowance, and the 200,000-a-month abuse fuse (which the billing console has an ask-us-to-raise-it path for).
Schedules themselves are not the constraint — runs are. Projects are unlimited and free, but they do not multiply the allowance: runs are counted across the account, so projects organise your work rather than reprice it.
The inputs stay bounded (60-second floor, payload and retry ceilings), and the subscription is the whole bill for the first 20,000 runs a month. Past that the meter is public and tiny — $17 per million runs, prepaid — and there is still no per-job pricing, no seat count and no invoice surprise.
One plan. It includes every other Parsons product.
Monthly or yearly — a year costs exactly two months less than paying month to month. No seats, no enterprise tier, no free tier. For Scheduler the number that matters is printed on the card — the runs your whole account gets.
- $17 per million runs past the 20,000 — prepaid, printed here, no invoice surprise
- Cron, interval and one-off — every feature on this page
- Signed fires, retries, dead-letter, delivery log
- Failure alerts by email, webhook or Tracker issue
- Every other Parsons product, same login
Projects are unlimited, and free.
One for the business, one for the client work, one for the thing you are not sure about yet — each with its own data, its own members and its own spend caps, at no extra cost. There is nothing to upgrade to and there are no seats to buy. If the tool you are leaving bills by the job, by the workspace or by the seat, none of those lines exist here: a second project, and a second person, cost nothing.
One subscription, the whole platform.
Scheduler is one product on it. The same $15 is also your auth service, your database, your object storage, your outbound email and the rest — with real allowances, not trial-sized ones.
“Is a scheduler worth $15?”
On its own, honestly, maybe not — a single-purpose cron monitor can come in under that, and the comparison table above says so in its own row. But $15 is not a scheduler price. It is the whole account. A mainstream CRM is $48–$99 a month for one seat; a hosted auth service passes $1,000 a month at 100,000 monthly users; here both are included, and the auth users are uncapped. Most people arrive already paying more than $15 for exactly one of the things on this list.
Then there are the lines we never add. Nothing is charged by the seat — bring the co-founder, bring the contractor. Nothing is charged by the workspace: projects are unlimited and free, each with its own data, members and caps. And nothing is charged by the job — the 20,000 included runs count the same whether they come from one schedule or a hundred, and so does the $17-per-million past them.
Consumption never hides inside it either. The things that genuinely cost money per unit sit on a prepaid wallet with its own ceiling: AI at provider cost × 1.5, a voice minute at $0.03, an outbound SMS segment at $0.02, a US phone number at $3.99/month — and runs past the included 20,000 at $17/million. You top it up on purpose. The subscription is access, not a loss-leader with a metered bill waiting behind it.
14-day free trial on your first subscription · billed monthly or yearly, your choice at checkout · cancel any time
Before you start the trial.
Do I have to move my code?
No. We call an HTTPS URL you already have. There is no SDK, no deploy step and no runtime of ours that your logic has to live in.
Can it reach something on my private network?
No — public HTTPS only, and we re-check at create time and again at every single fire. Internal hosts, cloud metadata addresses, loopback, private and CGNAT ranges and IP literals are all refused.
Will it ever run twice?
Delivery is at-least-once. Dedupe on Parsons-Idempotency-Key and keep the keys 24 hours. We will not claim exactly-once, because nobody honestly can.
How exact is the timing?
Best-effort to within seconds of the slot — not to the millisecond, and never faster than one fire per 60 seconds.
My endpoint is up but the thing it checks is down. Then what?
Return 503. We only ever see the outcome of the delivery, so a health-checker that returns 200 while its target is on fire will never alert. This is the single most important line on this page if you are using us as a monitor.
Who watches the scheduler?
Health alerts cover the delivery outcomes of your schedules. We do not claim to detect our own outage. If a schedule is load-bearing enough to need that, run an independent heartbeat against your own endpoint as well.
Can I edit a schedule?
You replace it. Same id, whole object, version bumps. There is no partial update — fields you omit go back to their defaults.
Does the free trial take a card?
Yes. It is a Stripe Checkout subscription with 14 trial days, so Checkout collects a payment method. Cancel any time inside the trial and you are not charged. The trial is first-subscription-only.
Can I pay by the year?
Yes. $150/yr against $180 paid monthly — exactly two months free. You pick the interval at checkout — the plan, the allowances and the feature set are identical either way.
What happens to my schedules if I cancel?
Fires stop. The schedules, their configuration and their delivery history are kept, not deleted — the cost-stop pauses the clock rather than shredding the data.
Are my headers and payload visible to you?
They are encrypted at rest and redacted on every read. Through the console and through MCP you get ‹set› — presence, never the material.
What counts against the 20,000?
Actual runs, account-wide, per 30-day month — including run_now. The first 20,000 are included in the $15; past that, runs draw from your prepaid credits at $17 per million, tallied daily. With no credits on the account, schedule creation parks at the allowance instead; and 200,000 a month is the abuse fuse where everything stops until you ask us to raise it.
Can I use this without an AI?
Yes. The console does full CRUD — create, pause, resume, run-now, delete, test-alert — through the same functions the MCP tools call. The AI path is an option, not a requirement.
Register the schedule. Get on with your day. We'll tell you if it stops landing.
$15/mo or $150/yr · 14-day free trial, cancel any time.