Usage & latency

Every job is measured, and the measurements are rolled up so you can answer "who is calling what, how often, how fast, and how often does it fail" for any utility, any API key and any time window.

What is measured per job

Measure	From the job	Meaning
Outcome	status	succeeded or failed (counted), with the error code for failures.
End-to-end latency	timings.totalMs	Accept → finished: what the caller experienced, including queueing, retries and the R2 copy.
Utility (Lambda) latency	timings.upstreamMs	Time inside the utility itself.
Queue time	timings.queueMs	Async jobs only: accept → a worker picked it up.
Storage time	timings.storageMs	Copying outputs to R2.
Attribution	API key, or the console user	Every job belongs to exactly one key — or to "Console playground" for runs from the console.

End-to-end vs Lambda latency is the most useful pair: when both rise together the utility itself got slower (bigger documents, a cold start); when only end-to-end rises, time is going to queueing or storage.

What counts

• A job counts once it is finished (succeeded or failed), in the time bucket of its finish time. A job that runs for 10 minutes lands in the bucket where it finished.
• Cancelled jobs aren't counted.
• Requests rejected before a job exists — invalid input (400), auth (401/403), rate limit (429) — are not jobs and aren't counted here. They show up only in the gateway's request logs.
• Console playground runs are counted under Console playground, not under any key.

How rollups work

Every 30 seconds the finished jobs are rolled up into 5-minute buckets per utility × API key × source × mode. Each bucket stores counts and two latency histograms (end-to-end and Lambda) with fixed boundaries, in milliseconds:

25 · 50 · 75 · 100 · 150 · 200 · 300 · 400 · 500 · 750 · 1 000 · 1 500 · 2 000 · 3 000 · 4 000 ·
5 000 · 7 500 · 10 000 · 15 000 · 20 000 · 30 000 · 45 000 · 60 000 · 90 000 · 120 000 ·
180 000 · 300 000 · 600 000 · 900 000 · (above)

Why histograms: percentiles can't be averaged — the p95 of a week is not the average of its hours' p95s. Histograms, on the other hand, add up exactly. Any view — a 30-day window, one key, three utilities together — is computed by summing the underlying buckets' histograms and reading the percentile off the sum.

• p50 / p95 / p99 are interpolated linearly inside the histogram bucket the rank falls in, so they're accurate to that bucket's width (e.g. a p95 of "2.4 s" means somewhere in 2–3 s, most likely near 2.4 s). Latencies above 15 minutes report the top boundary.
• avg is exact (sum ÷ count).
• Success rate is succeeded ÷ (succeeded + failed).

Rollups are rebuilt from raw jobs for the last 15 minutes on every tick, so late finishers are always included and a missed tick heals itself. Dashboards are at most ~30 seconds behind.

Raw jobs are deleted after 90 days; rollups are kept indefinitely, so usage history outlives the job records.

Windows

Window	Chart resolution	Compared with
1 h	5 minutes	the hour before
24 h	1 hour	the previous 24 h
7 d	6 hours	the previous 7 days
30 d	1 day	the previous 30 days

The ▲/▼ on the request tile compares the window with the one immediately before it.

Where to see it

Console page	Shows
Dashboard	Totals for all utilities: requests (with delta), success rate, end-to-end p95 (p50/p99 beneath), Lambda p95, jobs in flight (queued / running), requests-over-time (succeeded vs failed), p50/p95 latency over time, recent failures, and a health row per utility.
Utilities → a utility → Overview	The same, scoped to one utility, plus its recent jobs.
Usage	A row per API key (requests, success rate, p50/p95, and a per-utility breakdown) and a row per utility (requests, failures, success rate, p50/p95/p99, average Lambda time, last used).
Jobs	The raw jobs behind the numbers — filter by utility, status, mode, source, key.

External (guest) accounts see all of these scoped to their own keys.

Finding the slow ones

Dashboard p95 spiking? Open Jobs, filter by the utility, and sort your eye down the Duration and Lambda columns; the job page's timing bar shows whether the time went to the queue, the Lambda or the R2 copy.