tools/call request handled by your server. It is counted whatever the outcome — a crash is still a call.
Where it appears
Per day, or per hour
The chart is gap-filled: every bucket in the range gets a point, so a quiet day plots as zero instead of vanishing and making the line look continuous when it is not. Ask for a single day and the grain becomes the hour — twenty-four points rather than one, which is the only way a one-day window is a line at all. Anything wider stays daily. The API decides this and sendsgranularity beside the series.
It comes from tool_hours whether a filter is on or not, so a filtered series and an unfiltered one cannot disagree about a day. There is no second table holding the same totals at a coarser grain, which is how two tables come to disagree.
Stacked by outcome
One series could not say whether a spike was traffic or crashes, so the bars are stacked: ok, empty, and failed — with the first-call rate on a right axis as a dashed line that breaks where the nightly pass has not reached. Three bands, not five. There are three outcome hues in the palette and no fourth a reader could tell from the others; three shades of one red says these differ while giving nobody a way to know which is which. So colour groups the failures and the tooltip separates them —bad_args, tool_errors and crashes are sent per bucket beside the errors band, and a row appears only when it happened.
Buckets are UTC
Ingest buckets a call into an hour withdate_trunc('hour', started_at at time zone 'utc'), and every read uses the same clock. A call at 23:50 UTC belongs to that day, not to the next one in your timezone. Hourly labels on the chart are UTC for the same reason.
The one place local time is used is the live call feed, and deliberately: a call is a moment, a bucket is not.
The timezone on your company profile is display only. Nothing reads it into a query.
Retries are calls
A model that callssearch_orders, gets nothing useful, rewords and calls again has made two calls. Both are counted here.
That is the point: the gap between calls and first-call success is the work your tool descriptions are making the model do.
Why totals can lag by seconds
The SDK buffers and flushes every 5 seconds or 30 calls, and ingest replies202 before writing. A call made a moment ago may not be visible yet. Nothing else lags — only retries, first-call success and tool pairs wait for the nightly pass.