Cron Expression Parser

Cron syntax: field-by-field reference

A cron expression has five space-separated fields, each controlling a unit of time:

• Minute (0–59) — which minute of the hour
• Hour (0–23) — which hour of the day (24-hour clock)
• Day of month (1–31) — which day of the month
• Month (1–12 or JAN–DEC) — which month
• Day of week (0–7, where 0 and 7 are both Sunday, or SUN–SAT)

Special characters: * means "every", */n means "every n units", a-b is a range, and a,b,c is a list. For example, 0 9-17 * * 1-5 runs at minute 0, every hour from 9–17, on weekdays only.

Common cron patterns with examples

• * * * * * — every minute
• 0 * * * * — top of every hour
• 0 0 * * * — daily at midnight UTC
• 0 9 * * 1-5 — weekdays at 9am
• 0 0 * * 0 — every Sunday at midnight
• 0 12 1 * * — first day of each month at noon
• */15 * * * * — every 15 minutes
• 0 0 1 1 * — once a year, January 1st at midnight

Cron on Railway and Docker

Railway supports cron jobs natively via its Cron service type — you define the schedule in the Railway dashboard and the command to run. The schedule uses standard 5-field UTC cron syntax. Common use cases: database backups, email digests, cache invalidation, and scheduled data fetches.

In Docker Compose or a plain Dockerfile, the traditional approach is to use a system cron daemon (crond in Alpine, cron in Debian/Ubuntu). The crontab is added during the image build. For containerized workloads, a simpler pattern is often to use a lightweight process manager or a sleep loop in an entrypoint script — this avoids the complexity of running two processes in one container.

In Node.js applications, libraries like node-cron and @nestjs/schedule let you define cron jobs in code without touching the OS scheduler. This is often the easiest approach for Railway deployments where the service is already running a Node process.

Debugging missed or double-fired cron jobs

Missed fireshappen when a service is down or restarting at the scheduled time. Most cron implementations (including Railway) don't backfill missed runs — they simply skip them. To handle this in your application, track the last successful run time in your database and run a compensating check on startup.

Double fires happen in distributed systems when multiple instances of a service are running and all of them respond to the schedule independently. The fix is a distributed lock (Redis SET NX, Postgres advisory locks, or a dedicated scheduler service) so only one instance processes each scheduled event. Railway's Cron service type handles this for you by running exactly one container per scheduled trigger.