Use case
Full cron expressions for your Heroku apps, without the Scheduler add-on.
Heroku Scheduler is great for three cadences: every 10 minutes, hourly, daily. Crontap is great for every other cadence, including 17:00 in your customer's timezone, the second Tuesday of the month, or every Friday at 16:30 in Australia/Sydney.
Free plan · no credit card required
The problem
Why this is painful without the right tool
- Heroku Scheduler only ships three intervals: every 10 minutes, every hour, every 24 hours. Anything else (every 4 hours, weekdays at 09:00 local, Monday only) is not expressible.
- Each scheduled task spins up a one-off dyno per execution; the dyno-time bill compounds for tasks that fire many times a day even when the actual work is one HTTP call.
- There is no central view across multiple Heroku apps: each app has its own Scheduler config, and a multi-service org ends up clicking through several dashboards to audit cron.
- Heroku Scheduler is best-effort and not exact-time; the Heroku docs say so explicitly. For renewal mailers and finance jobs that need to fire at 00:05 local, that is a real liability.
The fix
How Crontap solves it
Keep your Heroku deploy. Drop the Scheduler add-on. Crontap calls your https://yourapp.herokuapp.com URL on a real cron expression in any IANA timezone, with retries and failure alerts to email / webhook (Slack / Discord / Telegram). One dashboard across every Heroku app you own.
0 17 * * *One concrete pattern from the dataset, archetyped: a Heroku customer running daily user notifications at 17:00 Europe/Berlin via Crontap, exactly because Heroku Scheduler is UTC-only and 24-hour-cadence. The schedule fires POST /chapter-one/v1/send-daily-notification on local time; the Heroku app handles the user query and the mail-render. Same customer also runs a daily image fetch at 05:00 and a deploy trigger at 03:00 from the same Crontap dashboard, all in their team timezone.
For the head-to-head decision frame, pricing math, and a migration playbook from Heroku Scheduler, see Crontap vs Heroku Scheduler.
Auth is whatever your Heroku app expects. Crontap stores arbitrary headers per schedule (bearer tokens, Heroku platform API tokens, custom X-Heroku-App-Token) and sends them on every run. The endpoint stays public-by-DNS but the auth check lives in your handler, which is the same model as every other production HTTP service.
FAQ
Common questions
- Does this save money?
- Yes on most workloads. Heroku Scheduler spins a one-off dyno per task execution, which costs dyno-seconds even for tasks that are pure HTTP. Crontap calls your existing web dyno over HTTPS, which uses no new dyno-seconds beyond what your handler already uses.
- Security?
- Heroku app URLs are public. Add a bearer token header that Crontap sends on every run and verify it in your app. The endpoint stays open at the DNS layer; the auth lives in the handler. Most teams use the same pattern they use for incoming webhooks from third parties.
- What's the shortest interval Crontap supports?
- Every 1 minute on paid plans. Free tier available for slower cadences. Heroku customers in the dataset typically run at every 5 minutes, hourly, or daily; minute cadence is rare because the workloads that need it tend to be pollers that already moved off Heroku to a smaller-unit-of-cost runtime.
- Can I run different cadences against the same app?
- Yes. Each schedule is independent; create one per cadence (a hourly poll plus a daily aggregate plus a Monday-only weekly digest, all hitting different routes on the same Heroku app). They share the dashboard and alerting, but Crontap runs each on its own clock.
Related guides
Adjacent use cases
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
/wp-cron.php?doing_wp_cron=1
Schedule
"every 5 minutes"
Next
in 23s