Use cases · PaaS

PaaS cron jobs and scheduled HTTP triggers

Heroku Scheduler is fixed at 10 minutes. Railway has no native scheduler. Render and Fly.io mostly require always-on workers. The spokes here are the external HTTP cron pattern for each.

About this topic

PaaS

7 itemsUse cases

PaaS schedulers historically optimised for one shape: keep a worker process alive, point it at a clock library, ship logs through your standard observability. That works for one service in one environment. The moment you need full cron expressions on Heroku (its built-in Scheduler caps at 10 minute, hourly, or daily), or any cron at all on Railway (no native scheduler exists), or cron without paying per-execution dyno cost, the path of least resistance is to expose a cron URL on the service and have something external fire it.

These spokes cover that: Crontap hits your /api/cron route on Heroku, Railway, Render or Fly.io on whatever expression you need, in any timezone, decoupled from the platform's deploy cadence. One Crontap dashboard sees all of your PaaS environments, including separate prod and staging URLs, with failure alerts on every schedule.

Use cases on PaaS

7 items

Related on Crontap

The same PaaS topic, from other angles.

FAQ

Common questions on PaaS

Why not just keep clockwork running inside the worker dyno?
You can. Cost is the usual reason teams move: a worker dyno running 24/7 to fire one job a day burns money. Decoupling the clock means the worker can scale down or sleep entirely, and the schedule lives in a place you can change without redeploying.
Heroku's Scheduler is free. Why pay for an external one?
Heroku Scheduler is fine for the three cadences it supports (10 min, hourly, daily). The moment you need a real cron expression (every Tuesday at 02:30 in Europe/Berlin, or every 7 minutes between 09:00 and 18:00 weekdays), it can't express that. Crontap takes any standard 5-field cron in any IANA timezone.
Can Crontap drive my Render/Fly.io app without it being always-on?
Yes. The HTTP request from Crontap wakes the app the same way any other request would. For platforms that scale to zero, the first request of the day pays a cold-start penalty; subsequent calls are warm. The schedule's run log shows duration so you spot the cold one.

More from Crontap

Topics across the site.

Every topic Crontap covers, in one row. Each one has its own page on the use cases 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