How these numbers are measured

An action is one tool call your agent made against a site: a search, a form submission, a record read, a document download. It is the unit every metered figure on the Usage screen counts.

Three things are NOT actions, and none of them is billed as one:

• A browser session. One session usually carries many actions, and a session that opens and does nothing counts zero.
• A page load, a redirect, or a retry inside a single action. An action that recovers internally is still one action.
• A message you send in chat. What the agent then does on your behalf is what gets counted.

An action counts as soon as it is attempted, whichever way it ends. Failures count. Actions your own permission rules refused count too, in their own figure, for the reason in the next section.

Every figure on /dashboard/plan covers the window in the dateline at the top of the page, which is the 7, 30 or 90 days you selected. "Just me" narrows the same measurement to the signed-in member; it is not a second calculation.

The figures are all projections of one query, so the per-site table, the per-surface split and the day-by-day chart add up to the headline by construction rather than by two reads agreeing. The page does not say so on every panel, because a number that adds up is the normal case.

The success rate is taken over the actions that were TRIED, not over every action counted.

An action your permission rules refused never reached the site. Nothing ran, so there was nothing that could have succeeded or failed, and putting it in the denominator would push your rate down every time a control did its job. A workspace that tightens its rules would watch its success rate fall, which is exactly backwards.

So the rate divides successes by actions that ran, and the surface prints that denominator beside the rate rather than leaving you to work it out. When every action in a window was refused, the denominator is empty and the rate shows a dash instead of 0.0%, with the reason next to it. Zero percent means everything you ran failed; a dash means nothing ran.

The dateline can show two counts, for example eight tracked sites of which six are ready to run now. They are a set and a subset, and the gap is real rather than a rounding artefact.

A tracked site is one your workspace added. It becomes ready to run when Rindler can actually serve it: the mapping has finished, a config version has been resolved, and the site is either yours by adoption or available to your plan from the shared catalog. A site that is still being mapped, one whose mapping failed, and one your plan does not reach are all tracked and none of them is ready.

Which is which is per site, so the answer is in the Coverage column of the per-site table on the same page, and in full on Site Mappings. The counts differ; the table says why.

Two figures on the Usage page do not sum the way a reader might expect, and both are correct.

Active agents, per site. One agent that worked on three sites is one agent for the workspace and three rows in the per-site table, so that column can add up to more than the workspace figure. The page says so, but only when the sum really does exceed the total.

Usage on sites you do not track. The rollup covers every site your workspace used, including ones nobody added. Those rows are listed and labelled "Untracked" rather than dropped, because a headline whose own breakdown cannot account for it is worse than an unfamiliar row.

Under "Just me" there is a third case. Some actions record no acting member, usually because they predate per-member attribution, so a personal figure is smaller than your true share by that remainder. The page prints the size of the remainder and when it was last seen, beside the figure it qualifies, so a smaller number never reads as a drop.

Usage answers how much your agents did and where. It does not answer how well.

Success by cause, the slowest actions, which sites break most often, and what a failed run actually did are on Activity & Performance, which reads the same events with a different question. The two screens count the same actions, so their totals for the same window agree; they differ in what they group them by.

Billing is a third thing again. Credits and what you have left are on the Billing screen, and the Usage page makes no credit read at all, which is why it never projects a date you will run out.

Overview answers what happened across your workspace over the selected window.

The window is the one selected in the page head, and it applies to every figure on the surface except the live session count, which has no window because it is an instant reading.

Performance reads the same actions Usage counts, over one site, and asks a different question: did they succeed, and where did the time go. Its window is the one named in the comparison table's column headers, 7 days unless the page says otherwise.

Every figure is scoped to the site in the picker, so changing the site changes the whole page. When the 7-day action figures cannot be read at all, the page falls back to a rate measured over the RUNS on the page (a run is one browser session, an action is one step inside it) and says which unit it fell back to, rather than printing one rate under another unit's label.

The comparison table holds two columns and no chart: the window before, and this one. That is two points, and a line between two points is a shape we did not measure, so we do not draw one. Both columns name the window length in their own header, so you never have to infer which 7 days a number covers.

Rindler refuses a comparison it cannot make. The speed row needs at least 20 timed actions on BOTH sides, plus a previous p95 above zero, before the server will compare them. Below that the previous cell reads "Not compared" instead of printing a number that looks compared, and the verdict sentence above the table says the same thing in words: about as much succeeded as before, but too few actions were timed to say whether things got slower.

"Slowest typical action" is the p95: 19 out of every 20 actions finished that fast or faster, and 1 in 20 was slower. We rank on the p95 rather than the average because a single 40-second outlier moves an average and tells you nothing about a typical run.

An action has to have been timed at least 3 times before Rindler will rank it. Below that floor one slow run would top the list on its own, so the action is left out and the ranking is PARTIAL by construction: it ranks the actions we have timed often enough to rank, not everything your agents did. The caption under the list says so, and a window with fewer than 3 timed actions in total prints that fact in the cell instead of a duration.

Time lost counts only the failures Rindler actually timed. A failure that ended without a recorded duration, a session that died mid-action for instance, is in the failure COUNT and out of the time TOTAL. That is why the two numbers do not move together: 12 failures can cost the time of 9, and neither figure is wrong.

The sentence on the page names both, which is what makes the remainder visible: "they cost 85.0s of run time across 20 timed failures" over 21 failures says one failure was never timed. A window where nothing was timed says there is no time cost to report rather than reporting a zero we did not measure.

An action your permission rules refused is counted separately from a failure, and it is in neither half of any success rate: not in the numerator, not in the denominator. A rule doing its job is not a broken agent, and counting a refusal against your success rate would penalise you for using the safety feature.

The refusal row appears only when the server actually reported a refusal count, because a workspace on an older server would otherwise read as a confident zero. Refusals are never coloured as a regression either: more refusals is the control working harder, not the site getting worse. What gets refused is yours to change, under your permission rules in the dashboard.

No money figure appears anywhere on Performance, and that is deliberate. We do not record what an order was worth, and we cannot prove that one action caused a sale, so a dollar cost on a failure would be our guess wearing your currency.

What the page gives you instead is the failure, the runs it touched, and the time it cost, each of them observed. Price it with numbers you own.

The Activity sub-view lists the runs on the site you have selected and charts the actions across every site. The two halves are measured differently on purpose, and the caption above each one says which.

A run is one browser session. A step is one thing done inside it, and it is the same event the Usage screen counts as an action, seen from inside one session rather than across all of them. So a run row's step count and the daily chart are counting the same events over different denominators, and their totals are not meant to match.

A run can succeed while its steps failed. Rindler retries a step that did not work and routes around it where the site allows, so a session that finished the job it was given is recorded as succeeded even though its step count includes attempts that failed on the way. That is why a row prints its step count and its outcome as two separate facts instead of implying one from the other: the outcome answers whether the work finished, the failed-step count answers how hard it was.

The recent runs list is one page. It is a single fetch of the 25 most recent runs on the selected site, newest first. The server stops filling that fetch at 25 and the dashboard asks for no separate count, so no figure taken from these rows is a count of the site's history. When the fetch comes back full there is more history behind it and the caption says so; when it comes back short, what you see is every run there is.

Who ran it. Each row names the agent that made the run: an MCP client such as Claude Code or Codex, a saved automation, or Chat. The agent is read from the client the run arrived on. A run that identified no client, and whose owner cannot be resolved either, is labelled "Not recorded" rather than left blank or filled in with the session id.

Whose runs you see. The list is fenced on you. A teammate's runs are their private content and no lens unlocks them, so switching between Whole workspace and Just me leaves this list unchanged; it changes the chart beside it, which counts actions across the whole workspace either way. Team-wide run and action totals are on Usage.

Runs that record no teammate. Some runs record no acting member: they ran before Rindler recorded who acted, or through a lane that never did. They belong to the workspace and to nobody in particular, so they are listed in their own block, are not openable, and are left out of the export and the agent filter. Their step by step evidence stays with the workspace owner.

The chart beside the sentence counts actions per day across every site in your workspace over the last 7 days, not runs on the selected site. A flat day inside a drawn chart is a measured zero. A reading Rindler could not take never draws a chart at all; it says so in place of one.

• The tools that produce these actions are in the tool reference.
• What an agent does when a site needs a login is in sign in to gated sites.
• For the full picture of sessions, actions, and structured records, see the docs overview.