When something breaks, the answer is spread across three places: the requests that failed, the log lines they wrote, and the change that went out just before. Infinite Haiku now has one page for all three, Logs & Traces. Its views can also be dropped into an incident report, by a person or by an AI agent, and they stay live there. Before every merge we checked its numbers against a design study’s own answers.

Why one page

An investigation usually starts with “something is wrong” and ends with “this change did it”. In between, you jump between a latency chart, a list of slow requests, one request’s spans, its log lines, and a deploy history. Every jump costs you the context you had: the time window, the service, the request you were looking at.

Logs & Traces keeps that context. One window, one filter bar and one breadcrumb sit at the top. Below them, ten views (we call them lenses) each answer one question about the same moment:

• Roster: which services are not OK, and since when;
• Changes: what was deployed or reconfigured, and did it hurt;
• Alarms: what IH’s alerts said;
• Heatmap: which requests were slow or failed;
• Compare: what two or three requests have in common;
• Path: where a route’s requests spend their time, and where they die;
• Trace: one request, span by span;
• Log board: one request’s log lines, in order;
• Stream: every log line of the window;
• Map: who calls whom, and which calls fail.

Pick a failed request in the heatmap and the trace opens on it. Press Esc and you are back where you were. Copy the link and a colleague lands on exactly the same view: the same window, the same box drawn on the heatmap, the same requests picked.

The same views inside an incident report

An incident report is only as good as its evidence. In IH, every lens is also a block you can put in an incident or on a dashboard. It is not a screenshot: the block is the live view, drawn by the same code, so the numbers in the report are the numbers on the page.

Agents can do this too. Through IH’s agent interface, an agent can open an incident and add a heatmap of the bad window, the failed request’s trace and its log stream. The person on call then reads a report whose evidence they can click into. We tested exactly that: an incident built by an agent, block by block, shows the same counts and rows as the page.

Poet does the arithmetic, your browser draws

IH’s datastore, Poet, runs in your infrastructure, next to your data. Every number on this page comes from Poet: heatmap bins, percentiles, the “did this change hurt” verdicts, log patterns, the Map’s layout. Part of it is prepared when data arrives, so opening a view does not mean scanning raw records. The browser only draws.

That matters for two reasons. The page stays fast as your volume grows, because the work is done once, where the data already is. And the data does not have to travel to a browser to be counted, so the footprint stays small. How it behaves at production volume is still to measure; this release was checked on a reference hour, not on millions of requests.

Checked against someone else’s answers

The design study came with its own synthetic hour of telemetry: 356 traces, 4,516 spans, 4,012 log lines and 4 changes, including a bad deploy and its rollback. It also computed its own answers over that hour.

We loaded that hour into IH as ordinary OpenTelemetry data, then compared IH’s answers with the study’s, family by family: 15 kinds of question, from heatmap bins to the Map’s hover cards. Where IH disagreed, we looked at why. Usually IH was wrong and we fixed it. Sometimes IH was right: the study had left one service out of its list, and IH kept it. Wherever IH knows less than the study pretended to (a team for a database, say), IH shows nothing rather than a guess.

Every view also has a browser check that drives the page and asserts what it shows. When the work merged, 448 of those assertions passed, plus 24 checks that compare a running Poet’s answers with the study’s. They now run as one command, so a later change that breaks a view is caught before it ships.

Judgement first, then speed

Years of design work made this fast, not a prompt. The product underneath (the datastore, the graphics engine, the incident model) has been designed and built by hand since 2024, and the design study for this page went through several rounds of our review before any code. AI coding agents then did the building, each owning its own part, and everything was checked together before it merged.

We made the calls an agent cannot: where IH should differ from the study, what counts as a job, where alarms come from, how the menu behaves. The agents brought back evidence; we decided.

What is next

Poet is being rewritten, and Kabuki is becoming a browser-only app that talks to Poet over a direct connection. The lenses stay as they are. The study’s answers and the browser checks are now the tests the new Poet has to pass before it replaces the old one.

If you run services and want this page on your own telemetry, follow the build on this blog, or write to us about a pilot.