Steward
Sign in

Documentation › Sponsor guides

Read the usage dashboard

/sponsor/usage is the surface a sponsor opens whenever they suspect something is "off" with cost or volume. This guide walks through reading it section by section, with a worked example for the most common question: "why did our burn spike?"

Background reading: Credit usage covers the underlying credit model; this guide assumes you know what a Standard / Deep / per-PR scan costs.

The page at a glance

Sponsor › Usage
Evaluation volume.

[ Total: 1,247 ] [ Done: 1,201 ] [ Running: 3 ] [ Queued: 0 ] [ Failed: 43 ]

Daily volume
┃   peak 89 / day
┃ ▁▂▃▄▆▆▇▆▅▄▅█▆▆▅▆▆▇▆▅▄▅▆▇▆▆▆▆▄▃
   2026-05-10                    2026-06-08

Top repos by evaluation count
| acme/api          | 412 | 8 failed |
| acme/billing      | 251 | 3 failed |
| acme/frontend     | 178 | 1 failed |
| acme/docs         |  62 | 0 failed |
| acme/sdk          |  44 | 0 failed |

Credits consumed (30d)         86.450
| Language    | Scan      | Jobs | Credits |
| go          | pr        | 1180 |  59.000 |
| typescript  | pr        |   67 |   3.350 |
| go          | standard  |   28 |  14.000 |
| go          | deep      |    2 |  10.100 |

Per-repo cost (30d)         5 repos
| acme/api      | 412 | 23.450 |
| acme/billing  | 251 | 18.300 |
| ...

Section-by-section

Status cards (top)

The five numeric tiles. Read them as a quick health pulse:

  • Total — total evaluations in the last 30 days. Compare against last month informally; a 3× jump without a fleet expansion is worth investigating.
  • Done / Running / Queued / Failed — distribution. In steady state, Done is ~95%+ of Total. Failed > 5% is the threshold where you go to Debug a failed evaluation for whichever repo's in the failed column.

Daily volume bar row

30 day-bars, oldest left. Hovering shows date + count. The peak label sits in the header.

Patterns to recognise:

  • Flat-ish with low jitter — a healthy steady-state team.
  • Weekly cycle — Mon–Fri high, Sat–Sun low. That's correct for a team-shaped tenant. Total weekly burn doesn't change.
  • A single tall day — almost always a backfill (someone installed Steward on a new repo + Steward backfilled the recent PRs) or a CI loop firing redundant push webhooks. Drill into the day on the Top repos table; one repo with most of the day's count is the giveaway.
  • A sustained 2× ramp — your team grew, or someone enabled per-PR scoring on a busy repo. Look at the Per-repo cost table: which repo's credits doubled?

Top repos by evaluation count

The 5 noisiest repos in the window. The Failed column flags in red when any failures land. A repo with consistently high count + zero failures is fine (it's an active repo, not a broken one). A repo whose evaluations are mostly failed is your investigation queue.

Credits consumed

Hidden when no metering data has accumulated yet; surfaces as "Credit + token spend will appear here" placeholder otherwise.

When it appears:

  • Total credits — running 30-day sum.
  • Per-language × scan-kind table — surfaces which kind of evaluation is driving cost. Typical shape: per-PR scoring dominates by count but is cheap per call (0.050 per row), while a handful of Deep Analysis rows account for a chunk of the total via the 5.0 × 9 = 45.0-per-call cost.

Read the Credits column carefully — credits are NUMERIC(12,3), so 45.000 means literal 45 credits, not 4.5.

Per-repo cost

Same total credits, attributed to each repo. Click a repo to open its fleet detail page.

The (removed) flag appears on repos that have been uninstalled. Their historical evaluations are preserved with the previous full name so credit attribution doesn't go missing.

Worked example: "Our burn doubled this week"

A common scenario. Walk through it on the dashboard:

  1. Status cards. Done count jumped from ~700 to ~1,400 between this week and last. Confirms the burn is volume, not unit-cost.
  2. Daily volume. The increase started on a specific day — say, May 31. Hover the bars on either side to confirm.
  3. Top repos. Which repo's count grew? Find a acme/api line that was previously ~150 and is now ~350. That's ~70% of the doubling explained.
  4. Credits consumed. Look at the language × scan-kind table. If the pr scan row grew but standard / deep didn't, the burn is per-PR scoring — likely the maintainer turned on per-PR auto-evaluation (the Team/Business tenant-flag flip) on a busy repo.
  5. Per-repo cost. Confirm the acme/api row shows the matching credit increase. The denominator is now obvious: a repo with a doubled PR rate produced a doubled per-PR burn.

What to do next depends on the cause:

Cause Action
Real growth in PR traffic Likely you'll hit your tier's daily cap soon. Plan to upgrade.
CI loop firing redundant push webhooks Check the repo's webhook delivery log on GitHub. A misconfigured force-push CI step can fire dozens of evaluations per actual change.
Backfill from a new repo install Will dissipate in 2–3 days. Don't react.
Per-PR scoring flipped on for a busy repo Decide whether the per-PR firehose is worth the burn. Flip it off via the maintainer admin surface if not.

Daily routine

Most sponsors check /sponsor/usage weekly at most. Daily is overkill (intra-day variance is high). Suggested cadence:

  • Mondays — quick glance at the status cards. If Total looks off vs. last week, drill in.
  • First week of the month — review the per-repo cost attribution. Right-size your tier if you're consistently using <10% of the cap (downgrade) or hitting it for >2 days in a row (upgrade).

What's next