Cron jobs on Railway, and what a five-minute floor rules out
Railway cron jobs run your service’s start command on a schedule. The model is a container that boots, does the work and exits — which is clean when it fits and awkward when it does not.
What Railway gives you
Railway Cron Jobs. A crontab expression on a service. Railway starts the service at those times; the service is expected to finish and exit.
- Minimum interval
- Five minutes
- Timezone
- UTC
- Overlap
- A run is skipped if the previous one is still going
- Timing
- Not guaranteed to the minute
- Requirement
- The process must exit cleanly
Checked against Railway 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 task is a short script that runs, finishes and exits — a backup, a nightly import.
- Five minutes or slower is enough and you are happy paying for the container boot each time.
Where it runs out
A process that does not exit blocks the next run
Railway does not terminate deployments for you. Leave a database connection open and the run never ends, so the following run is skipped — silently, and for as long as it takes you to notice.
You are booting a container to make a request
If the job is "call this endpoint", a whole service start-up is a heavy way to do it, and you pay for the start-up as well as the work.
Nothing under five minutes
Anything that wants to run every minute needs a different mechanism.
Scheduling it from outside
If the scheduled work already lives behind an HTTP route in a service you are running anyway, you do not need a second service at all — call the route.
That removes the cold start, removes the exit-cleanly requirement entirely, and gets you a per-run record with retries. Keep Railway cron for the jobs that genuinely want their own container, like a database dump.
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.