Bucket width for the returned buckets, expressed as a duration string: a number with a unit
suffix "s", "m", or "h" (e.g. "30m", "1h", "24h"). Units may be combined, e.g. "1h30m".
The response echoes the effective interval in normalized form (e.g. "300s" becomes "5m").
The interval must be a whole multiple of 1 minute. Which multiples are allowed depends on
how far back the range starts, because finer-grained data is retained for less time.
Divisibility — not size — decides the tier:
- Multiples of 24h (1 day), e.g. "24h", "168h": allowed for any range within the 13-month
retention period.
- Multiples of 1h that are not multiples of 1 day, e.g. "1h", "2h", "12h": the range must
start on or after 00:00 UTC six days before the current UTC day (roughly the last
7 days).
- Every other multiple of 1 minute, e.g. "1m", "5m", "30m": the range must start within
the last 48 hours. Note "90m" lands in this tier — it is larger than an hour but not a
whole multiple of one.
In addition, the range divided by the interval must yield at most 400 buckets.
Violations return INVALID_ARGUMENT (HTTP 400) naming the violated rule and the finest
interval that fits the range.
Buckets are aligned to the Unix epoch in UTC: hour-multiple intervals start on the hour,
day-multiple intervals at 00:00 UTC (note: a 7-day interval therefore starts buckets on
Thursdays). For intervals finer than 1 hour, buckets starting within the last 2 minutes are
omitted because their data is still arriving and would under-report; data_through in the
response marks where the returned data stops. Counts are attributed to buckets by the time
the platform recorded the stat, which can lag the event itself by up to ~65 seconds — at
minute granularity a burst of traffic may appear one bucket later than it occurred.
If unset, the server selects the finest interval permitted by the rules above and echoes it
in the response.
