Skip to content

Dashboard

The Dashboard at /dashboard/ is your per-user cost and cleanup view. It shows aggregate compute spend and storage costs across the runs you own, plus tools to bulk-delete the outputs of runs you no longer need.

The dashboard's universe is terminal runs only — succeeded and failed. Runs that are still queueing, registering, or in flight don't appear here, since they have no settled cost or finished outputs to act on. For operational triage of in-flight or registered runs, use the Runs List instead.

By default every section reflects only your runs. Cluster admins get an admin banner with cluster + user dropdowns to view other users' data — see Admin mode below.

Filtering

A single row of filters at the top of the page rescopes every section on the page to the same filtered set.

Filter Options
Time Last 7 days · Last 30 days (default) · Last 90 days · All time
Status All (default — succeeded ∪ failed) · Succeeded · Failed
Label Any · the labels seen on your runs
Size Any · > 1 GiB · > 100 GiB · > 1 TiB
Search Substring match across run name, output dir, project name, and labels

Filter state lives in the URL querystring, so the page is shareable and bookmark-friendly.

Sort

A separate sort dropdown lives in the runs-list header. Options: Newest first (default), Oldest first, Largest first, Smallest first, Name (A–Z), Name (Z–A). The size-based sorts put runs without recorded output sizes at the bottom.

?names= mode (advanced)

When the URL carries ?names=run-a%20run-b, the dashboard switches to a specified-set view: filter row and admin banner are hidden, and the listed runs are shown regardless of time scope or other filters. This mode is intended for tools that surface deletion candidates (a future MCP tool, for example) and hand the user a pre-populated dashboard URL to review and confirm.

Sections

Delete-status strip

A sticky banner at the top of the page surfacing your recent delete_outputs jobs. Visible whenever you have at least one delete job in-flight, or a terminal one created in the last 24 hours.

The banner shows count badges for failed / in progress / succeeded, and a colored top-edge stripe (red / blue / green) tracks the worst state present. Click Details ▾ to expand a per-job table with run name, status, age, and outcome (bytes freed on success, error message on failure). The expanded panel scrolls if you have many recent jobs.

While any job is in flight, the strip auto-refreshes every five seconds so you can watch progress without reloading the page. It stops polling once all jobs reach a terminal state.

Summary band

Five stat cards across the top:

  • Runs in scope — the total count after filters
  • Compute spend — aggregate cost from cost_and_performance_data.total_cost
  • Output storage — total size of live (un-deleted) outputs
  • Storage cost range — annual cost across the Archive Instant tier ($STORAGE_COST_PER_GB_YEAR_MIN) to the Frequent tier ($STORAGE_COST_PER_GB_YEAR_MAX)
  • Failed — count of failed runs in scope

Compute spend over time

A bar chart showing aggregate compute spend bucketed by time. Bucket size grows with the time scope: daily for Last 7 days and Last 30 days, weekly for Last 90 days, monthly for All time. Empty buckets in bounded scopes are zero-filled so quiet periods read as gaps rather than disappearing between busy days.

Projected annual storage cost from runs in window

A cumulative line chart showing the annual storage-cost contribution of runs started in the active time window. The line starts at $0 at the window's left edge and accumulates as scoped runs add bytes to S3.

Two lines bound the range — minimum (Archive Instant) and maximum (Frequent), with the area between them shaded.

The chart is intentionally window-scoped, not lifetime — the question it answers is "how much annual cost did this week's runs introduce?", not "what is my total footprint?" Pick All time to see the lifetime trajectory.

Runs list

Full-width cards, 25 per page, sorted by the dropdown in the section header. Each card shows status, run name, workflow, start date, duration, labels, output prefix, size, compute cost, and annual storage cost range.

A Show all on /runs/ link in the section header takes you to the ops-triage view scoped to your runs.

Bulk-delete outputs

Each runs-list card has a checkbox. Selecting any cards reveals a sticky bottom action bar showing the selection's running totals: count, reclaimed size, and saved annual cost range. There's also a header-row Select all on this page checkbox.

There is intentionally no cross-page select-all: the runs you act on must be the runs you can see. If you need to delete a curated set across many pages, pre-stage the names via a tool that hands you a ?names=… URL.

Click Delete outputs… to open the confirm modal. The modal shows:

  • The run count and aggregate stats
  • A scrollable list of the selected run names (with sizes)
  • A confirmation input that requires typing exactly delete N run (or delete N runs if the count is plural)

The destructive button stays disabled until the typed phrase matches. On submit, each surviving run gets its own delete_outputs job — the same primitive used by the per-run delete on the run detail page. Job status appears in the Delete-status strip above.

The server silently drops runs that are no-ops:

  • Runs you don't own (defensive — there is no UI path that surfaces them)
  • Runs without an output dir
  • Runs whose outputs are already deleted
  • Runs that already have a delete job in flight

So the queued count reported in the success message can be smaller than the count you confirmed. The action is permanent: S3 objects go away, but tracker's run records, task data, and reports remain so you can still inspect what the run did.

Admin mode

If you have ClusterMembership(role=admin) on any cluster, or UserProfile.has_global_access set, you'll see an Admin mode banner above the filter row with two dropdowns:

  • Cluster — narrow to one of your admined clusters, or All admined clusters
  • User — view a specific user's runs, All users in scope, or yourself

Admin mode loads with your own data by default; you opt into a wider view by changing the dropdowns. Bulk-delete from admin mode acts on the selected user's runs and queues jobs as you (the admin), so the delete-status strip reflects what you initiated regardless of whose runs were affected.