Usage Dashboard

The Usage Dashboard gives admin users a real-time view of the organisation’s current billing-period consumption. It is available at Admin → Usage in the portal.

Overview

The dashboard renders four independent sections. All four data requests fire in parallel on page load. A failure in one section does not block the others — each section handles its own error state with an inline retry button.

Section	Source	Description
Current Period Summary	`GET /api/admin/usage/summary`	Request count vs plan limit, token totals, cost
Daily Request Trend	`GET /api/admin/usage/history?granularity=daily&limit=30`	30-day sparkline of request counts
Model Breakdown	`GET /api/admin/usage/by-model?granularity=monthly`	Per-model request counts and cost
Alert History	`GET /api/admin/usage/alerts?limit=20&offset=0`	Recent threshold-crossing events

Current Period Summary card

The summary card shows a colour-coded progress bar for the current billing period.

Progress bar colours

Colour	Threshold	Meaning
Green	< 80%	Normal usage
Amber	80–94%	Approaching limit — warning active
Red	≥ 95%	Critical — throttle active

The fill level is capped at 100% for display purposes even if percentage_used exceeds 100.

The card also shows:

Requests — current count vs plan limit (e.g. 834,200 requests / limit: 1,000,000)
Input Tokens — total input tokens consumed this period
Output Tokens — total output tokens consumed this period
Est. Cost — estimated USD cost, formatted to 4 decimal places (e.g. $47.8300)

The plan tier badge (e.g. ENTERPRISE_SAAS) is displayed next to the billing period dates.

Warning level

The warning_level field from the API drives the colour of the percentage label in the top-right corner:

`warning_level`	Label colour
`none`	Green
`warning_80`	Amber
`warning_95`	Red

Daily Request Trend sparkline

The sparkline shows the last 30 days of daily request counts. It is a native SVG <polyline> — no external charting library is required.

X-axis: dates across the period (first, middle, last labels shown)
Y-axis: request count, normalised to the min/max range of the visible data
Dots: data point markers (radius 3 for ≤ 14 days; radius 2 for longer windows)
Baseline: a faint horizontal line at the zero position

Tooltip titles on each dot show the date and request count:

Mar 7: 38,400 requests

The footer line shows the number of days plotted and the peak requests-per-day value.

Model Breakdown card

The model breakdown shows the top 10 models by request count for the current month. Each row includes:

Model ID (truncated with title tooltip if long)
Request count — e.g. 450,000 req
Estimated cost — e.g. $29.4000
Mini bar — proportional width relative to the top model’s count

Models are sorted by request count descending (highest-volume model first).

Alert History table

The alert history uses DataTableV2 to display the most recent 20 usage threshold alerts. Each row shows:

Column	Description
Threshold	Percentage threshold that triggered the alert (e.g. 80%)
At Trigger	Actual usage percentage when the alert fired, colour-coded (green / amber / red)
Requests	Absolute request count at trigger time
Triggered	Date and time the alert fired
Webhook	Delivery status badge — `Delivered` (green) or `Pending` (grey)

A Pending webhook status means the webhook was not successfully delivered at alert time. See the usage metering guide for details on webhook retry behaviour.

An empty table means no usage alerts have been triggered for the organisation yet.

Loading and error states

Each section independently shows a skeleton placeholder while its data loads. If a request fails:

The section displays the error message from the API detail field.
A Retry button re-fires just that section’s request.

Refreshing the whole page reloads all four sections in parallel.