Data area, time and data retention

A correct understanding of Regions, time fields, and data retention periods is a prerequisite for accurately reading overview indicators, event records, device statistics, and risk trends.

Region

A Region determines where an application's data services operate and forms the isolation boundary for server-side keys, Webhooks, and dashboard data. You cannot change an application's Region after creation. For selection criteria, isolation rules, and migration guidance, see Region and Data Compliance.

Console statistics time zone

The console uses UTC+0 for daily statistics. “Today” therefore means from UTC+0 00:00:00 to the current time, which may differ from the calendar day in your location.

When viewing day-level metrics or selecting a query date, understand the time range in terms of UTC+0. For example:

Today (UTC+0)
2026-08-25 00:00:00 to the current time

Server receipt time and business time

The Events page filters and sorts records by the time the GEELAB server received each request. Order, login, and other timestamps recorded by your business systems may come from different clocks and time zones. Normalize time zones before comparing logs, then use request_id to locate the event. For Webhook delivery timestamps and troubleshooting, see Webhooks.

Plan data-retention period

Your plan's data-retention period limits the events, devices, and risk statistics available in the dashboard. After data expires, both event details and aggregates calculated from those events may change. For retention effects, archiving recommendations, and billing scope, see Quotas, Rate Limits, and Data Retention.

Advice when reading data

Before querying events, first confirm the current organization, application, region and time range.
When comparing business logs, confirm the time field and time zone used by both parties.
When looking at the "Date of First Occurrence", pay attention to whether it has a "storage period" qualification.
When investigating risk signals, continue from summary cards into specific events and don’t just look at aggregate numbers.
When long-term auditing is required, external log or data archiving should be planned according to enterprise requirements and the console should not default to permanently saving all events.