Kibana Timezone Configuration for Multi-Regional User Access

Question

Kibana handles temporal data by storing timestamps in UTC and typically converting them to the browser's local time zone for visualization. While the Advanced Settings provide a global timezone override to standardize the display across the instance, this setting applies universally to all users regardless of their physical location.

In environments where teams operate across multiple regional time zones, a global override prevents the browser-based detection from functioning, while the default browser setting may lead to inconsistencies when discussing specific time-window boundaries during cross-regional collaboration.

Is there a mechanism to define time zone preferences at the user or space level rather than the global instance level?
  How does the system resolve conflicts between a global timezone override and the local browser offset during date histogram aggregation?

Tasadduq Burney · Answer

Answer
No. Standard Kibana does not offer a native per-user or per-space timezone preference. The only configurable option is the instance-wide Advanced Setting timezone. It is binary: Browser or a fixed IANA zone such as America/New_York. When a fixed zone is set, browser detection is disabled for all users and all Spaces.
Conflict resolution for date histograms: a global override wins. The browser offset is ignored for display and bucket alignment.
Confirmed facts

Elasticsearch stores timestamps in UTC. Kibana never changes stored values.
With timezone = Browser, Kibana renders time-series in the client’s local offset. The same UTC event shows different wall-clock labels per user.
With timezone = , Kibana applies that zone globally. All users see the same labels regardless of their system clock.
The Advanced Setting is instance-wide and cannot be scoped to a user, role, or Space in standard Kibana 7.x-8.x.

Likely explanation for aggregation behavior
Date histogram aggregations are computed on the server in UTC by Elasticsearch. Kibana then shifts bucket boundaries and axis labels to the effective timezone before rendering. The effective timezone is:

Global override if set to a named zone
Browser local offset if set to Browser

Time range filters sent to Elasticsearch remain UTC. The shift is presentation only, which is why two users with different browsers can see different bucket edges when Browser mode is active, and identical edges when a global override is active.
Practical verification

Stack Management > Advanced Settings, search timezone. Note current value.
Open the same Lens date histogram in two browsers with different system timezones. Compare X-axis labels.
Open DevTools Network, inspect the Elasticsearch request body for a visualization. Time ranges are UTC epoch millis.

Assumption: behavior described matches Kibana 7.17 through 8.x. If you are on a newer 8.13+ build or using a custom plugin, verify in place. Current verification is recommended because UI paths for Advanced Settings have moved across versions.
One detail that changes the recommendation: what Kibana version and whether you require consistent bucket boundaries for cross-regional incident windows versus local wall-clock readability. With that, I can confirm if any experimental per-space settings apply to your build.

Kibana Timezone Configuration for Multi-Regional User Access

1 answer

Answer

Confirmed facts

Likely explanation for aggregation behavior

Practical verification

Your perspective belongs here.

0 question comments