Skip to content

Site and workspace timezones

Monitoring crosses timezones the moment your clients do. Two questions follow: which wall clock should timestamps display in, and which midnight decides where one day ends and the next begins in a report? UpAll answers both with a small hierarchy instead of one global setting.

The resolution chain

Each monitor's effective timezone resolves in order:

  1. Site — a monitor attached to a site uses the site's timezone. Sites default to Asia/Riyadh, and the zone can be set per site (add a site).
  2. Workspace — a monitor with no site (an internal monitor) falls back to the workspace's timezone, set in workspace settings (workspace settings and branding).
  3. Default — if neither is set, UpAll's platform default applies.

The practical rule: set each site's timezone to where that client actually operates, set the workspace timezone to where your team lives, and every monitor lands in the right zone without per-monitor configuration.

What uses the monitor's timezone

Day bucketing in reports. A monthly SLA report splits the month into days — daily uptime, daily incidents — and which day a check or an outage belongs to is decided by each monitor's resolved timezone. An outage at 23:30 in the client's zone lands on that day in their report, instead of leaking into the next day because someone else's midnight arrived first. This is what makes a report read correctly to the client whose systems it describes (monthly SLA reports).

What uses the workspace timezone

Clock times shown to your team. Incident timestamps — in the console and in alert emails — are presented in the workspace timezone, so during an incident everyone reads the same wall clock. Reports use it for clock times too, and each report carries a footnote naming the timezone, so a reader always knows which wall clock its times are in (report language and timezone).

Why storage is UTC underneath

Every timestamp UpAll stores is recorded in UTC — one unambiguous global timeline — and timezones are applied only when something is displayed or bucketed into days. This is the standard discipline for time-series systems, for good reasons:

  • Arithmetic stays honest. Uptime percentages, incident durations, and failure streaks are computed on one linear timeline, never across a zone change.
  • No ambiguity. Wall-clock time can skip or repeat where daylight saving applies; UTC never does.
  • Zone changes are safe. Change a site's timezone and future displays and day bucketing use the new zone, while the underlying record never moves. Nothing is rewritten, nothing double-counted.

The upshot: you configure timezones for the humans reading the output — the data itself never depends on them.