Cron jobs on Render, and what they cost
Render cron jobs are a first-class service type that runs a real container on a schedule. They are solid, and they are billed per job — which is the fact that decides most of these pages.
What Render gives you
Render Cron Jobs. A service type of its own, from a Git repo or a Docker image, running a command on a cron schedule.
- Cost
- Minimum $1 per cron job per month
- Billing
- Prorated by the second of running time
- Timezone
- UTC
- Maximum runtime
- 12 hours per run
- Overlap
- At most one run of a job active at a time
Checked against Render docs on 18 August 2026. These change — if a deploy disagrees with this page, believe the deploy and tell us.
When this is the right answer
Most people reading this should keep what they have. It is worth being specific about when:
- The job needs a real container — system dependencies, a large dataset, a long-running import. Twelve hours of runtime is far beyond what an HTTP scheduler should be asked to hold open.
- You want the code deployed from the same repo, and a dollar a month is not the constraint.
Where it runs out
Every schedule is a separate billed service
Ten small jobs means ten cron job services and a minimum ten dollars a month, before runtime. The cost scales with how many things you schedule, not how much work they do.
A container boot per run
For a job whose real work is one HTTP request, the boot is most of the cost and most of the latency.
UTC only
A job that should follow your business day has to be adjusted by hand twice a year, or accept the drift.
Scheduling it from outside
If your Render web service already exposes the work behind a route, a cron job service is a second thing to deploy and pay for. Point a scheduler at the route instead.
Keep Render cron jobs for the heavy, container-shaped work — that is what they are good at, and no HTTP scheduler should be holding a connection open for twelve hours.
What getNodi adds
getNodi calls a URL on a schedule and tells you what happened. Any schedule down to your plan’s floor, in your timezone rather than UTC, with retries, a record of every run — status, latency, response — and an alert the first time one fails. Credentials are encrypted at rest and requests can be HMAC-signed so your endpoint can verify they came from us.
The free plan runs 3 jobs hourly and needs no card, which is enough to find out whether this works for you. What it will not do is run a container, hold a connection open for an hour, or execute your code — it makes HTTP requests, and everything above is a way of making that enough.