Spot the workspaces that need attention
A new org-wide Usage view scores every workspace on reliability, speed, change, and drift — and floats the flakiest, slowest, and most stale straight to the top. No setup, built entirely on runs you already have.
Some version of this question lives in every platform team's head: "Which of our workspaces is the flaky one?" Or the slow one. Or the one nobody has applied in three months that's quietly drifting away from reality. The honest answer used to be a shrug — or an afternoon of clicking through run histories one workspace at a time.
The new Usage tab answers it for the whole org at a glance.
What's new
Open Insights → Usage and you get a fleet-level read on how your infrastructure is actually running over the last 7, 30, or 90 days:
- Org KPIs up top — apply success rate, deploy frequency, median run time, plan no-op rate, and how many workspaces have gone stale.
- A "needs attention" row — the stalest, flakiest, and slowest workspaces, pulled out for you automatically.
- A sortable breakdown table — every workspace scored and ranked, worst first by default, so the ones that need you are already at the top.
Each workspace is measured on the things that actually predict pain:
- Apply success rate, with failed plans and failed applies counted separately — a plan that won't compile and an apply that blew up mid-run are very different problems.
- Flaky reruns — an apply that failed, then passed on a re-run with no code change (same commit). That's the real definition of flaky, and it's now a number you can sort by.
- Recovery time and consecutive failures — how long a workspace stays red, and how deep the holes get.
- Deploy frequency and lead time — the DORA-style velocity view, per workspace.
- Plan no-op ratio — how many runs changed nothing at all (noisy triggers, wasted CI).
- Resource churn, trigger mix (UI vs pull request vs schedule), and drift activity.
Why it matters
- Find the flaky code, not the busy workspace. Ranking by a raw failure count just punishes your highest-traffic workspaces. Success rate plus same-commit reruns points at the actual flakiness.
- Catch the abandoned ones. A workspace that hasn't had a successful apply in 90 days is a drift risk hiding in plain sight. Now it surfaces in the stale count and the leaderboard instead of waiting for an incident.
- See your GitOps maturity. The trigger mix shows how much is driven by pull requests and schedules versus people clicking Apply by hand.
- Triage the slow ones. The slowest-workspaces list and median run times tell you where pipeline time is actually going.
Under the hood
No new instrumentation, no agent changes, nothing to turn on — this is built entirely from run data InfraDots already stores. The failed-plan-versus-failed- apply split comes straight from per-phase run outcomes, and "flaky" is computed by walking each workspace's apply history and spotting a failure followed by a same-commit success.
It's all computed on read, scoped to your chosen window, with a fixed, bounded set of queries no matter how many workspaces you have — so the view stays fast whether your org runs ten workspaces or several hundred.
For automation, the same data is available at
GET /api/organizations/<org>/insights/?window=30d, with sort, order, and
pagination on the per-workspace breakdown.
What's next
Two timing metrics are already wired into the layout and will light up shortly: a plan-versus-apply duration split — so you can see which phase actually eats the clock — and approval wait time, the minutes an apply spends parked waiting on a human.
Turning it on
Nothing to flip. Open any organization, head to Insights, and select the new Usage tab.