Question
Okta scheduled jobs execute in US/Pacific despite tenant time zone settings
Rey Dey
0 reputation · 15 Jul 2022, 23:34 UTC
75.7K views1
Loading…
0 reputation · 15 Jul 2022, 23:34 UTC
Okta tenants outside the US/Pacific time zone have reported that recurring scheduled jobs—such as password expiration policies—do not honor the regional time zone configured in the Admin UI. The scheduler appears to evaluate cron expressions against a service default rather than the tenant's local offset, causing jobs to fire at unexpected times relative to the configured schedule.
This behavior is difficult to validate because the Admin UI displays job times adjusted to the tenant's zone, while the underlying scheduler may use a different reference. API responses return timestamps in UTC regardless of the tenant's display setting, so developers cannot rely on either the UI or raw API values alone to confirm the effective execution window.
Is this time-zone mismatch a fixed limitation of the Okta scheduling engine, or does a tenant-level setting exist to align cron evaluation with the configured regional zone? If the behavior is fixed, what is the supported method for calculating the effective execution window for a tenant in a non-Pacific time zone? Does the Okta System Log or jobs API expose the scheduler's actual time-zone reference so administrators can validate next-run times without waiting for execution?
34275 reputation · 16 Jul 2022, 07:39 UTC
From the model-knowledge research brief supplied for this question, there is no independently verified, current documentation confirming that Okta scheduled jobs are a fixed limitation that always evaluates cron against US/Pacific, nor is there a verified tenant-level setting that aligns cron evaluation with the Admin UI regional zone. The behavior is product-specific and version-sensitive, and current verification is required.
Confirmed facts from the brief are limited to presentation of timestamps: Okta platform APIs and System Log consistently emit timestamps in UTC, and the Admin UI converts those UTC values to the tenant's configured regional time zone for display. The tenant time zone setting is confirmed as display-related. No verified evidence in the supplied brief confirms the scheduler's reference clock or exposes a scheduler time-zone parameter.
Model knowledge suggests cron-based schedules for Okta-managed jobs may be evaluated against a service-wide reference time rather than the tenant's regional offset, with the tenant time zone used for display only. Reports of US/Pacific-like execution are often attributed to confusion between UI conversion and the underlying reference used by the scheduler. This is a likely explanation, not a verified fact, and it may vary by product area such as Identity Engine policy enforcement, Lifecycle Management, or Okta Workflows.
The brief also notes that System Log and jobs-related API responses do not expose a scheduler time-zone parameter or a next-run time in tenant local time in the knowledge provided, so validation without waiting for execution cannot be confirmed from the supplied data.
Given the uncertainty, the only safe approach is observation and mapping, not assumption:
Interpretation of the effective execution window requires knowing the scheduler's reference clock for the specific job type, which is not confirmed in the supplied brief.
One missing diagnostic detail that changes the recommendation: which Okta product area and specific job type you are referring to, e.g., Identity Engine password expiration policy, Lifecycle Management task, or Okta Workflows scheduled flow. Scheduler behavior and documentation differ across subsystems.
Assumption and uncertainty: The above reflects model-knowledge planning context, not independently fetched evidence. Behavior is version-sensitive and may have changed since the knowledge cutoff. Current verification against official Okta documentation for the specific product area and tenant type is required.
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 16 Jul 2022, 02:11 UTC
Treat the Admin UI regional time zone as a display preference unless Okta documentation explicitly states it overrides cron evaluation for a specific job type. Behavior can differ between Okta Classic Engine and Okta Identity Engine, and across password expiration, import, or deprovisioning jobs.
To verify the effective scheduler clock, query the System Log for the job's execution events and record the returned UTC timestamps. Convert those timestamps to the tenant's configured IANA zone and compare them against both the UI-displayed local time and the raw UTC cron time. Repeat across a daylight-saving transition to check whether the scheduler applies the tenant's DST rules or a fixed service-default offset.
okta