Timestamps & timezones

Every timestamp the API returns is ISO 8601 in UTC. Every timestamp the API accepts must be ISO 8601 (UTC preferred, offsets accepted, naive local time rejected).

Format

The T separator and explicit timezone are required for parsing safety — naive local-time strings are rejected with VALIDATION_ERROR.

Time windows on analysis create

{
  "description": "checkout errors",
  "timeStart": "2026-04-25T14:00:00Z",
  "timeEnd":   "2026-04-25T14:30:00Z"
}

timeEnd must be strictly after timeStart. Both must be in the past — timeEnd more than 60 seconds in the future returns INVALID_TIME_RANGE.

Date-range filters on lists

fromDate and toDate use the same format and apply to the resource's createdAt field:

GET /v1/analyses?fromDate=2026-04-01T00:00:00Z&toDate=2026-04-25T23:59:59Z

Both are inclusive on the lower bound, exclusive on the upper bound when sub-second precision is provided; for full-day inclusion, use T23:59:59.999Z.

Clock skew

Allow a few seconds of skew between your client and the API. If your client is asking for an analysis on a time window that ends "now", subtract 30 seconds to avoid edge-case races where logs haven't yet been ingested by your log source:

const timeEnd = new Date(Date.now() - 30_000).toISOString();

Display in the dashboard

Times in the dashboard render in the viewer's browser timezone but are stored as UTC. When you fetch a resource via API and display its timestamps, convert to local time on your side.