Skip to main content
Thirteen of the sixteen metrics are counted live, as payloads arrive. Three are not: All three are questions about a sequence rather than about a call, so none can be answered at the moment a call is recorded.

​
What it does

At 02:00 UTC, for the previous day, per MCP: walk each session’s calls ordered by started_at, apply the retry rule, update tool_hours.retries and tool_hours.first_call_ok, and populate tool_pairs from consecutive calls. The retry rule is on First-call success: the same tool called twice within one session inside 30 seconds, with a different args_hash. Both writes group by client as well as tool, matching the key of tool_hours — so a client’s first-call rate is those rows summed over tools rather than a second pass. The retry window itself still partitions by session and tool and not by client: a session belongs to one client, so adding it would change nothing and would suggest a call could be retried by a different model. 02:00, not midnight. The retry rule reads 30 seconds past the end of the day it is walking — a call at 23:59:50 can be answered at 00:00:05, and the pair has to be visible or the last call of every day is judged with its follow-up missing. Re-running a day is safe. The pass assigns rather than adds, so backfilling a range is a loop over one day at a time.

​
The other two jobs

Alerts run fifteen minutes later, not beside the pass. first_call_rate is written by the pass, so a rule on it evaluated in the same minute would read a half-computed rate — firing on a figure that was never true, or missing one that was. Cleanup must run after the pass, never before: deleting yesterday’s calls first makes retries silently zero, forever, with no error anywhere.

​
nightly_as_of

Every metric response carries it: the last day the pass has covered, or null when it has covered none of the range.
Use it to label the three lagging figures. The dashboard shows them as as of yesterday.

​
Today is excluded from the denominator, not just the numerator

This is the part worth understanding, because it explains a number that would otherwise look wrong. first_call_ok is zero on days the pass has not walked. If today’s calls were in the denominator, the headline metric would sag through the day and jump back at 02:00 — a number that moves on its own is worse than one that is a day old. So the denominator is calls on covered days only. A range that is entirely today has no rate at all.

​
Three states, not two

That third case is the one place in MCPulse where “not yet” is honest rather than evasive. A zero there would claim every call failed. In the per-day sparkline the same three states apply: a day with no calls plots zero and keeps the line continuous, and a day the pass has not reached is null so the line breaks rather than inventing a dip.

​
First day

On day one, all three read as not yet computed. Insights that depend on first-call success do not fire. This is normal.

​
Events exist so they can be deleted

The pass reads calls, the raw per-call rows. Only one other thing does — the live call feed, which needs rows to point at. Every dashboard figure comes from tool_hours. That separation is deliberate: calls pile into the millions, while an hour’s counters stay tiny and add up correctly across any range. A cleanup of calls by your plan’s retention is built and deliberately not switched on yet, and it must run after the nightly pass.