Live calls

The per-call feed: every call your server handled, newest first, on a five-second poll — and the only screen in MCPulse that reads individual rows.

/m/:id/events is the one page in the product that shows calls rather than counts.

Everything else reads tool_hours, which is a set of counters. A counter has no rows to point at, so nothing built on one can answer the question this page exists for: did the call I just made land?

What a row is

One tools/call handled by your server.

Column
When	Local time, with seconds
Tool	Which tool ran
Client	Which model called it
Outcome	ok, bad_args, tool_error, crashed, or ok marked empty
Duration	Milliseconds
Response	Bytes

There is nothing sensitive here, because there is nowhere for it to be: the table has no column for arguments or results. See Security.

The timestamp says which day

Today 14:22:31, Yesterday 09:04:07, then Aug 24, 09:04:07 for anything older.

Three deliberate choices in that. A 24-hour clock, because 03:45:59 PM reads as the small hours until you reach the suffix. Seconds always, or a burst a second apart is five identical rows. And local time, unlike every day-bucketed figure in the product — those are UTC because the metrics tables are, and a timestamp is a moment rather than a bucket.

It pages on the server, ten at a time

Every page is reachable. It used to fetch the newest fifty and page through them in the browser, which meant a month of calls had a fourth page and no fifth.

A cursor, not an offset. The feed is live: before=9788 is the same ten calls however many arrive above it, where offset=20 shifts by one every time a call lands and shows page three a row that page two already showed.

The cursor is the row id, a bigserial — so two calls starting in the same millisecond still have an order, and a poll asking for id > 412 can neither skip a call nor repeat one. The page is then sorted by started_at for display, because the SDK batches and arrival order is not quite call order.

The response also carries total: every call matching the filter, counted without the cursor bounds, so the pager can say “page 3 of 480”. It runs the same where as the page — a total counted with different filters is a page count nobody can act on — and it deliberately ignores before, or the total would shrink as you paged and the last page would claim to be the only one.

Filtering

One dropdown in the page header, carrying the five outcomes.

A closed list rather than a search box, deliberately: there are five outcomes and a fixed vocabulary, and typing “crash” lets somebody type a word matching nothing and conclude the feed is broken. Changing the filter starts again at the first page — a different filter is a different feed.

Retention is your plan’s

The subtitle says so: “8,710 calls recorded. Calls are kept for N days as per your plan.”

Plan	Calls kept
Free	7 days
Pro	90 days
Scale	365 days

Only this page loses anything when a call is deleted. Every figure in the product comes from tool_hours, which is never deleted — so retention costs the feed its tail and costs no other screen a thing. That is the whole reason the split exists. See Counters and calls.

The cleanup job is written and not yet scheduled. Nothing has been deleted so far.

It refreshes every five seconds

And says nothing about it. Metrics re-read every 30 seconds, this page every 5, and neither on a hidden tab. There is no “Live” badge and no pause button: refreshing is what a feed does.

Related

• Calls — the counted version
• Outcomes — what each one means
• The nightly pass — the other reader of these rows