Most AI chat reporting answers questions about the aggregate: how many conversations, how many handovers, what it cost. The diagnostics screen answers a different and much more specific question — what happened in this one conversation, in order — and it is the screen you want open when somebody forwards you a chat that went wrong.
It is also a screen that rewards knowing how it is built, because it assembles its timeline from several independent sources and each of those can come up short without saying so.
One conversation, four record sources
You give the screen a session identifier and it returns a single chronological timeline for that session, built by merging four separate kinds of record.
Conversation messages — the visitor turns, the assistant replies, and the system events that bracket them. These tell you what was said and when.
AI requests — each call made to a model provider, with the feature that made it, the provider and model, a status, and how long it took. These tell you what the assistant was doing between messages.
Handoffs — each attempt to pass the conversation to a person, with a reason and an outcome.
Tool calls — each time the assistant invoked one of your configured tools, with a status and a duration. If you have given your assistant actions to take, this is where you find out whether they ran.
Everything is timestamped in UTC. If your team is not in UTC, translate before you conclude that something happened at an implausible hour; this trips people up on the handoff log too, and for the same reason.
Each source is capped separately
The screen does not fetch an unbounded history. Each of the four sources is limited to its most recent rows, and the limits are not the same — handoffs are fetched at a noticeably lower cap than messages, model requests and tool calls.
Two consequences follow, and both matter for long conversations.
The timeline you are reading is the tail of the conversation, not the whole of it. The rows are collected newest-first and then sorted oldest-first for display, so a long session opens mid-story with no marker saying so. If the beginning is what you need, and the conversation ran long, this screen is the wrong tool — go to the transcript itself.
The four sources can also start at different points. Because the caps differ, a conversation long enough to hit them will show model requests reaching further back than handoffs, or the reverse, and it is easy to read that as an event not having happened when it simply fell outside its own source's window. When a conversation is long enough for this to be plausible, check the count strip at the top before concluding anything from an absence.
A missing source looks exactly like a quiet one
This is the most important thing to understand about the screen, and nothing on it tells you.
Each of the four sources is fetched defensively. If the underlying record store is not present for your account, or is present but missing a field the screen expects, or simply takes longer than a few seconds to answer, that source is skipped and the page renders anyway with whatever the other three returned. There is no warning, no partial-data banner, and no difference in appearance between a source that had nothing to report and a source that was never successfully read.
The design is deliberate and defensible — a diagnostics page that fails to load when one record store is slow would be useless exactly when you need it — but it puts an obligation on the reader. A timeline showing messages and no tool calls means either that no tools ran or that the tool records could not be read, and the page looks identical in both cases.
The practical habit is to treat an empty category as a question rather than an answer. If you expect tool calls and see none, check a session you know invoked a tool. If that one also shows none, the problem is the reading, not the conversation.
The counters and the colours disagree
The screen shows a strip of counters — how many of each event kind, and an error count — above a timeline where each row carries a coloured status pill. The counter and the pill are computed by two different rules, and they do not always agree.
The error counter works from a short list of statuses it considers healthy: the ordinary success values, plus a blank status. Anything outside that list increments the error count. The coloured pill works the other way around, turning red only when the status text contains one of a few obviously-bad words.
The gap between those two rules is real, not theoretical. A tool call that times out is recorded with a status meaning exactly that, and a tool that was refused because your site requires a person to approve actions that change data in an external system is recorded with a status meaning refused. Neither of those words is on the red list, so both render as a green pill — while both are counted in the error total, because neither is on the healthy list either.
When the error count and the row colours disagree, believe the count. It uses the stricter rule. Then read the status text on each row rather than its colour, which is good practice on this screen regardless.
Two smaller notes in the same area. A blank status counts as healthy, so a record written without a status will never inflate the error total. And conversation messages are always recorded as a plain fact and can never be counted as errors — the error count only ever refers to model requests, handoffs and tool calls.
The needs-attention list is noisier than it looks
Alongside the timeline, the screen offers a short list of recent sessions worth looking at: sessions from the last week that had a handoff which failed, errored, or found nobody available, or that carry any error text at all. It is capped at a dozen and ordered by most recent.
The trap is in that middle condition. Nobody being available is the normal, correct outcome when a visitor asks for a person outside your staffed hours — it is the assistant behaving properly, not a fault. On any site that runs AI chat overnight, this list will fill up with entirely ordinary events, and reading it as a defect list will send you chasing nothing. The handoff log guide makes the same point about the same signal, and it is worth internalising once.
There is a second, subtler thing about these rows. The timestamp shown is the latest activity for that session, but the reason and outcome labels are aggregated across all of the session's handoff records rather than taken from that latest one. On a session with a single handoff they agree. On a session with several, the label beside the time may describe a different event than the time does. Treat each row as a pointer to a session worth opening, not as a description of a single moment.
How to actually use it
The screen is at its best for one specific job: a customer or an agent reports that a conversation went wrong, you have the session identifier, and you want to know whether the assistant answered badly, called a tool that failed, tried to reach a person and could not, or simply did what it was told.
Work down the timeline in order and ask what the assistant was doing between visitor turns. A long gap with no model request is a different problem from a fast model request with a bad answer, which is different again from a tool call that returned an error the assistant then papered over. Those three failure modes look identical in the transcript and completely different here, which is the whole reason the screen exists.
What it is not is a measurement tool. It answers questions about one conversation; the aggregate questions belong on the reporting screens, and measuring whether AI chat is working covers those. Reading individual diagnostics timelines is how you form a hypothesis, not how you confirm one.
Put it into practice
- Keep the session identifier in your escalation notes. Without it the screen can only show you the recent-attention list.
- Read the timestamps as UTC and translate before drawing conclusions about timing.
- Treat an empty category as a question, not a finding. A source that could not be read looks the same as one with nothing to say.
- Believe the error count over the row colours when they disagree; the count uses the stricter rule.
- Do not treat nobody-available as a defect in the attention list. It is the correct outcome when nobody is staffed.
- Go to the transcript for long conversations. Each source is capped, so a long session shows you its tail.
Used as intended, this is one of the more honest screens in the product: it shows you the machinery rather than a summary of it. That honesty comes with the obligation to read it carefully, because a page assembled from four independent sources is only ever as complete as the least cooperative of them, and it will not tell you which one that was.