Scheduled Heroku Scheduler jobs execute at unexpected times after changing app region

Question

Developers expect Heroku Scheduler to trigger jobs according to a local time zone that matches the application’s intended audience, especially after moving the app to a different geographic region. The platform does not automatically adjust the scheduler’s execution time based on the dyno’s region, leaving the timing dependent on the TZ configuration variable.

Because the TZ var must be set explicitly and only takes effect after a dyno restart, any change in region or desired local time requires manual coordination. Add‑ons such as Heroku Postgres continue to store timestamps in UTC, so the application must still perform zone conversion for display purposes. This creates a gap between the configured region and the actual runtime behavior of scheduled tasks.

What is the recommended workflow for updating the TZ variable when an app is migrated to a new Heroku region without causing missed or duplicate Scheduler runs?

How can teams verify that Scheduler jobs are honoring the new TZ setting after a dyno restart without introducing additional logging or metric overhead?

Tasadduq Burney · Answer

Recommended WorkflowHeroku Scheduler evaluates cron expressions in UTC unless the app-level TZ config var is set. Changing the app's region does not modify this variable, so scheduled jobs continue to fire at the original UTC offsets. To migrate cleanly:Pick a quiet window where no job is scheduled to run within the next 5–10 minutes on either the old or the new time zone.Set the new TZ value (e.g., America/Los_Angeles) via the dashboard or CLI: heroku config:set TZ=America/Los_Angeles -a your-app.Restart all dynos so the new environment variable is picked up: heroku restart -a your-app. This restarts web, worker, and the one-off scheduler dynos.Confirm the next run time in the Scheduler dashboard — the “Next run at” column should now show the expected local time for the new zone.If you cannot guarantee a quiet window, scale the scheduler formation to zero (heroku ps:scale scheduler=0), apply the TZ change, restart, then scale back up. This eliminates any chance of a job firing during the transition.Verification Without Extra LoggingAfter the restart, use one of these lightweight checks:Scheduler UI: Open the add-on dashboard; the “Next run at” timestamp reflects the active TZ setting.One-off dyno: Run heroku run bash -c 'date' -a your-app. The output shows the dyno’s current time in the configured zone, confirming the variable is active.Next job log: Let the next scheduled job execute normally. Its log line (if the job prints a timestamp) will display the new local time. No additional instrumentation is required.Assumptions and CaveatsThis guidance assumes the Common Runtime (not Private Spaces) and Heroku Scheduler Standard. Private Spaces may use a different scheduler implementation. Add-ons such as Heroku Postgres continue to store timestamps in UTC; application-level conversion remains necessary for display.One diagnostic detail that would change the recommendation: Are you using Heroku Scheduler Standard or the newer Heroku Scheduler (beta) with custom clock processes? The beta version can run on a dedicated clock dyno that may require a separate restart.

Scheduled Heroku Scheduler jobs execute at unexpected times after changing app region

1 answer

Recommended Workflow

Verification Without Extra Logging

Assumptions and Caveats

Your perspective belongs here.

0 question comments