PlatformCron jobs
Cron jobs, with no worker to keep alive.
Antideploy calls a path on your app on a schedule. It wakes the app if it is asleep, so a nightly cleanup, a digest email or a sync runs without a background process that has to stay up. Your agent writes the endpoint and schedules it.
- Standard cron, in UTCFive fields, or @hourly, @daily, @weekly and @monthly
- A plain HTTP callA GET or POST to a path on your app, marked as cron
- Wakes a sleeping appThe call reaches your app's public address, so it wakes to serve it
- On every planThree jobs per app, Free included
01How it works
Write the endpoint. Schedule it.
The thing your agent writes for a nightly task is a route. Antideploy only has to call it.
Your agent schedules what it writes.
When your agent writes the endpoint that does the nightly work, it schedules it in the same breath, instead of ending its turn with a chore for you in the dashboard. A job is a path, a method and a schedule.
- Five-field cron in UTC, or @hourly, @daily, @weekly or @monthly
- The method is POST unless you say GET
- To change a schedule or a path, remove the job and add it again
$ API=https://antideploy.com/api/v1
# call POST /api/cron/nightly every day at 03:00 UTC
$ curl -X POST "$API/cron?applicationId=$APP_ID" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"schedule":"0 3 * * *","path":"/api/cron/nightly","method":"POST"}'
An endpoint, not a process.
A run is a request to your app's public address plus the path, with the header x-antideploy-cron: 1. It is given up after 60 seconds, so keep each run short. Anyone can send that header, so an endpoint that does real work should also check a secret of its own.
- A cron library inside your server does not run, because the app sleeps when idle
- Ten failures in a row pause the job, and resuming it resets the count
- Each job shows its next and last run, its last status and any error
// Express: the work your schedule calls
app.post("/api/cron/nightly", async (req, res) => {
// anyone can send the cron header, so check a secret of your own for real work
await deleteExpiredSessions();
res.sendStatus(200);
});
02What you get
Scheduled work, without a scheduler to run.
Apps sleep when nobody is using them, so a clock inside your server stops with it. A schedule outside the app does not.
-
Schedules in plain cron. Five fields in UTC, with the usual shortcuts. A job runs at most every five minutes, and each app can have three.
-
No background process to keep alive. A job is an HTTP call. It wakes the app, runs, and lets the app go back to sleep, so you pay nothing for the time in between.
-
Your agent does the scheduling. It writes the endpoint and creates the job through the API, and can list, pause, resume and remove jobs. The console has a Schedules panel for the same thing.
-
Every job reports on itself. Each job shows its next run and its last, the status of the last run and its error, and how many failures there have been in a row.
-
A header, and a secret of your own. Every run carries
x-antideploy-cron: 1. Because anyone can send a header, an endpoint that does real work should also check a secret that only your app knows. -
Pause without deleting. Pause a job while you fix its endpoint and resume it afterwards. Resuming resets its failure count.
03Limits
The same on every plan.
- 3
- jobs per application
- 5
- minutes between runs, at the fastest
- 60
- seconds before a run is given up
- 10
- failures in a row pause a job
Cron jobs are in the free plan. Schedules are in UTC.
04Reference
How a job runs.
Everything a job does, in one place.
| Rule | How it works |
|---|---|
| Schedule | Five-field cron in UTC, or @hourly, @daily, @weekly, @monthly. |
| Request | A GET or a POST to your application's public address plus the path. POST unless you say GET. |
| Header | x-antideploy-cron: 1 on every run. |
| Time limit | A run is given up after 60 seconds. |
| Jobs per app | Three, on every plan. |
| Shortest interval | Runs are at least five minutes apart. |
| Failures | Ten in a row pause the job. Resuming it resets the count. |
| Where to manage them | The Schedules panel in the console, or the API. |
05Before you commit
Here's where it stops.
A platform that only tells you what it is good at is one you find the edges of in production. These are cron jobs'.
-
In-process schedulers do not run
A cron library inside your server stops when the app sleeps. Use a scheduled job here instead. The analyser tells you about this before you deploy.
-
Three jobs per app
On every plan. Put small tasks behind one endpoint if you need more of them.
-
Five minutes at the fastest
Runs are at least five minutes apart. Work that must happen more often needs a different approach.
-
One minute per run
A run is given up after 60 seconds, so keep each one short.
-
UTC only
Schedules are written in UTC. Convert from your own time zone.
06Questions
Cron questions, answered.
Anything else? Write to us and a person answers.
support@antideploy.comCan I run a background worker or a queue consumer?
Not today. Only the web process runs, and apps sleep when idle, so a loop inside it will not stay alive. Use a cron job to call a path on a schedule, or a webhook.
What time zone are schedules in?
UTC. Write the schedule in UTC and convert from your own time zone.
How often can a job run?
At most every five minutes. Runs are at least five minutes apart.
How many jobs can I have?
Three per application, on every plan.
Does a job wake a sleeping app?
Yes. A run is a request to your app's public address, so the app wakes to serve it. The first request after a quiet spell can take several seconds, well inside the 60 seconds a run is allowed.
What if my endpoint takes longer than a minute?
The run is given up after 60 seconds. Keep each run short, and do the slow part in smaller steps over several runs.
What happens if a job keeps failing?
Ten failures in a row pause the job. Fix the endpoint and resume it, which resets the failure count.
How do I stop strangers calling my cron endpoint?
Anyone can send the x-antideploy-cron header, so an endpoint that does real work should also check a secret of the app's own.
How do I change a schedule?
Remove the job and add it again. You can pause and resume a job without removing it.
Can my coding agent create jobs?
Yes. It can list, create, pause, resume and remove jobs through the API, the same things the console's Schedules panel does.
+The rest of the platform
Everything else your app can use.
Every service is created by your coding agent, wired into your app, and included in the plans. See the whole platform.
- Hosting
- Static sites
- Deployments
- Database
- Authentication
- File storage
- AI models
- Custom domains
- Environment variables
- Logs and monitoring
- Security checks
- Console
- Agent API
Facts on this page were checked against the live platform on 5 October 2026.
Schedule something. In one sentence.
Paste the sentence into your agent. It writes the endpoint and schedules it, so there is nothing left for you to set up in a dashboard.