Blog · PaaS

Heroku, Render, Railway and Fly.io cron alternatives

Every PaaS ships some scheduler. None of them ship one with per-job timezones, 1-minute cadence on the cheapest plan, and alerts to your ops channel. These posts close the gap.

About this topic

PaaS

4 itemsBlog

Heroku Scheduler floors at 10 minutes and gives you three slots before you outgrow it. Render Cron Jobs cost about $1/mo per cron and run inside the platform's dyno semantics. Railway has no first-party cron, so most teams write an in-process scheduler that dies on every redeploy or stand up a separate worker service for one job. Fly.io's recommended cron pattern is a Machine in scheduled mode, which works but is overkill for an endpoint that just needs to be called every five minutes.

Crontap drives them all the same way: point at the public app URL (or a private one with a shared-secret header), pick the cadence (down to 1 minute on Pro), pick the IANA timezone, set the failure alerts. Redeploys don't affect the schedule, because the schedule isn't running inside the PaaS. You get one dashboard for jobs on Heroku, Render, Railway, Fly.io, and anywhere else you happen to host. The posts below cover each platform's specific seam (the 10-minute Heroku floor, the per-cron cost on Render, the missing Railway cron, the Fly.io Machine alternative).

Blog on PaaS

4 items

Related on Crontap

The same PaaS topic, from other angles.

FAQ

Common questions on PaaS

Heroku Scheduler is free and right there. When do I outgrow it?
When you need anything more often than every 10 minutes (the Heroku floor), need a per-job timezone (it's account-wide UTC), or need failure alerts (Heroku logs the run but won't page you). The Heroku Scheduler alternative post walks through the cadence math.
My Render dyno crashes mid-cron sometimes. Will Crontap retry?
Yes. Configure the schedule with retries and Crontap will resend on a 5xx response. Combined with a heartbeat for the worker-is-dead-and-not-responding case, you cover both halves of the failure space.
Railway has no cron. Is the right move an in-process scheduler?
Only if you accept that the schedule dies on every deploy. The more durable shape is an external HTTP cron pointing at a /cron/* route on the Railway service. Crontap keeps firing through redeploys, and the route can be as thin as app.get('/cron/sync', ...).
Fly.io has Machines in scheduled mode. Is that better?
For a heavy job that needs its own VM, yes. For an HTTP route that needs to be poked every few minutes, an external cron is lighter: one round-trip, no Machine to spin up, no cold start, and the schedule shows up on the same dashboard as the rest of your jobs.

More from Crontap

Topics across the site.

Every topic Crontap covers, in one row. Each one has its own page on the blog surface.

Ready to fix it?

Point Crontap at any URL. Pick any cron. Done.

WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.

Free forever tier ・ No credit card required

GET

/wp-cron.php?doing_wp_cron=1

Running
Your next schedule

Schedule

"every 5 minutes"

Next

in 23s