Report language and timezone

Two settings decide how a monthly SLA report reads: the language it renders in, and the timezones that define its days and times. Both are resolved around the client, not around whoever happens to download the file.

The report speaks the client's language

Each client record has a report language setting. If it's set, the client's reports render in that language; if it's blank, the workspace default applies. What the setting deliberately ignores is the reader's interface language: your console can be in Arabic while a client's report renders in English, or the reverse. The report is the client's document — it should read naturally to them, not to the engineer who exported it.

One practical consequence: monitors require an Arabic name and optionally take an English one. If any of your clients receives English reports, fill in the English names too, so the per-system table reads cleanly in both languages.

The workspace default language lives in your workspace settings; see Workspace settings and branding.

Which day a check belongs to

Daily figures have to answer a deceptively simple question: when a check runs at a few minutes to midnight, which day does it count toward? UpAll answers it per monitor, using the monitor's own timezone:

1. If the monitor is attached to a site, the site's timezone wins.
2. Otherwise the workspace timezone applies.
3. If neither is set, the default (Asia/Riyadh) is used.

So a client whose site sits in a different timezone gets daily numbers that match that site's actual local days — an outage at 23:50 local time lands on the day the client experienced it, not on the next day in someone else's zone. This is the same resolution order used across the product; Site and workspace timezones covers it in full.

Which clock stamps the times

Day bucketing decides which bucket a check falls into; clock times are a separate question. Every timestamp printed in the report — incident start times, above all — uses the workspace timezone, and a footnote at the bottom of the report states which timezone that is. One clock for the whole document keeps the incident log coherent even when a client has sites in more than one zone.

In short

If a client questions a number, check the language and timezone settings before anything else — most "wrong" daily figures turn out to be a day boundary landing where a different timezone would put it. For what the numbers themselves mean, see What's in a report.