Dashboard tour

A tour of the app, from the cross-project Home page down to a single span.

Home

Home shows every project at once and is where you land after signing in. Totals compare with the window before (24 hours against the 24 hours before, for example), and the Needs attention list flags what's worth a look, each with a link to the matching traces.

Minimum volumes keep quiet services from raising false alarms. The 30-day range has no comparison, since older spans have been deleted. Below the list: a health card per project, top errors, and the slowest operations across all projects.

Project overview

Requests, error rate, p95 and p99 for the project, charts of requests (with errors) and p95 latency over time, and a table of services. Click a service to see its traces.

Traces

One row per trace, newest or slowest first. Filter by service, span name, minimum duration and errors only. Filters live in the URL, so a filtered view can be bookmarked or shared with a teammate.

Logs

What your services wrote, newest first, filtered by service, level and a substring of the message. Click a line for its attributes and a link to its trace. A trace's own lines also appear under its waterfall, in the order they were written. See Send logs for how to send them and how long they're kept.

Errors

Failed spans and spans that recorded an exception, grouped so that one bug is one row: occurrences whose messages differ only in ids, numbers, emails or quoted values fall together. Each group shows how many times it fired in the range, how many traces it touched, a trend and when it was last seen. Handled marks a group whose spans recorded an exception but didn't fail.

Open a group for occurrences over time, the latest stack trace and recent examples, each linking to its trace. Grouping happens at ingest, so spans stored before an instance had it don't join a group; their exceptions are still in the span's events.

Outliers

Answers "why are these slow?" (or failing) without guessing which field to group by. Pick the outliers — the slowest 5% or 1% of requests in the range, or the failed ones — and knotel compares them with everything else: every promoted column, span attribute and resource attribute, ranked by how much more common its top value is among the outliers. A result reads like "48% of slow requests are GET /conversations, against 6% of the rest".

• Each card is one lead, strongest first; the top three show, the rest fold under weaker leads. Fields telling the same story — a route, its span name, its method, the raw URL — share one card, led by the most specific, with the rest under Same story.
• Every card says how often the value is bad. Slow every time (3 of 3) means the endpoint, query or host is slow on its own: fix it there. Only 12% of these are slow means something else picks out the bad ones: Narrow to this reruns the comparison inside that value to find it.
• The slowest (or latest failed) examples open straight into their trace.
• Numbers that rarely repeat, such as memory or payload sizes, are compared as ranges (≥ 224M). (set) and (not set) compare whether a field is present at all, which often means the outliers come from different code.
• Up to 1,000 outliers and 1,000 other spans are sampled evenly across the range, weighted by sample rate. A difference that few outliers could show by chance isn't reported, and with fewer than 20 outliers the page says so and offers a longer range.

A correlation is where to look, not the cause: slow requests from one organization may be slow because that organization has the most data. Turn on All spans to compare database and client calls too.

Trace detail

The waterfall shows every span on a shared timeline, indented under its parent and colored by service; error spans are outlined. Collapse a subtree with its arrow. Selecting a span shows its duration, self time (excluding children), time on the critical path, offset, error message, attributes, events with stack traces, links to spans it continues from (such as the producer of a queued message) and resource attributes.

Above the waterfall, Where the time went totals the critical path — what the request was actually waiting on — by what each span did, and Repeated queries lists database queries run five or more times in one trace with only their values changing, the usual sign of a loop that could be one batched query. Pick a row to highlight its spans; a dark line under a bar marks its critical stretch.

Sessions and Agents

Sessions lists browser visits, and the people behind them under People when your pages call knotel.identify(). A session opens its traces, which carry the backend work it caused. Agents lists AI agent conversations with their model calls, tool calls, tokens and estimated cost; opening one shows every step in order. Both are empty until spans carry the attributes — see Sessions, people and agents.

Service map

Which services call which, across all projects. See Service map.

Usage

What the instance used this month and what it's likely to cost on Cloudflare. See Usage and costs.

Settings

• Projects: create, and delete (with all their spans).
• Members: add a teammate with a starting password, or remove one, which signs them out and revokes their tokens.
• Access tokens & MCP: personal tokens for AI assistants. See MCP.

How fresh the numbers are

Every range is cached so pages open at once: results are at most 30 seconds old for 15 minutes, a minute for 1 hour, 2 minutes for 6 hours, 5 for 24 hours, 15 for 7 days and 30 for 30 days. When a cached result is older than that, you still see it straight away while a new one loads for the next look. A trace is cached once nothing in it has ended for 5 minutes. The refresh button always asks for the latest.

Ranges inside the hot window (7 days by default) come from D1 in milliseconds. Older ranges are read from the columnar store with R2 SQL and take a few seconds the first time, then come from the cache.