Morning cost and capacity dashboard for your Browserbase account

Build an app my engineering and ops team opens every morning to see what our Browserbase account is actually spending and whether anything is stuck. Treat this as a spend and capacity dashboard rather than a debugging console. The questions it answers are: how many browser minutes and how much proxy data are we burning, how much concurrency headroom is left, which sessions are running long, and how many minutes did we pay for that produced nothing.

The main screen opens with a spend row, one card per project. Use Browserbase List Projects to get every project the API key can see, then Get Project Usage for each one to read its browser minutes and proxy bytes. Show browser minutes, proxy usage converted to GB, and the change since yesterday taken from the history described below. Get Project Usage returns a running total for the project, not a per period figure, so never label the raw number as today's usage.

Beside the spend row, show a live capacity panel. Call List Sessions filtered to RUNNING to count the sessions in flight right now, and Get Project to read that project's concurrency limit, which lives on the project record. Display running against limit as a fraction with a headroom bar, and warn when we are close, because once the concurrency cap is hit new sessions get rejected outright.

Below that comes the runaway table: every session still alive past a threshold I set myself in the app, defaulting to 30 minutes, editable and remembered between visits. Build it from List Sessions filtered to RUNNING, compute elapsed time from each session's start time, and sort longest running first. Group the rows by the user metadata tag we set at session creation, so we can see which job or team is burning the minutes, and show a subtotal of elapsed minutes per group. Columns: tag, session id, region, started at, elapsed time, status. List Sessions accepts a user metadata query as well as a status filter, so let me narrow the table to a single tag when I want to.

Add a failures panel listing sessions that ended in ERROR or TIMED_OUT in the last 24 hours, built from List Sessions filtered to those statuses. Total up the minutes those sessions consumed and label it clearly as wasted spend, because they are paid for minutes that produced nothing. Group the failures by the same metadata tag so a job that fails over and over stands out immediately.

Because the usage API only ever returns a running total, take a snapshot every time the dashboard loads. Append a row to a Google Sheet with Append Values holding the timestamp, project id, project name, browser minutes, proxy bytes, running session count and concurrency limit. Read that history back with Get Values and use it to chart minutes per day, which is the difference between consecutive snapshots, and to show a week over week trend against the same weekday last week. If the newest row is less than five minutes old, reuse it instead of appending, so a morning of refreshes does not flood the sheet.

Clicking any session row opens a detail view for that session. Load Get Session for the full record, Get Session Debug URLs for the live view of a session that is still running, Get Session Logs for the Chrome logs, and Get Session Replays plus Get Session Replay Page for the video replay once it has ended. Include a Release Session button with a confirmation step so nobody kills a real job by accident. Note that Browserbase closes a session by requesting a status change rather than deleting it, so the button should request release and then reflect the new status. Also include a button that posts the session summary to Slack with Send a Message, covering the tag, elapsed time, status, minutes consumed and a link back, so I can hand it straight to whoever owns that job. Let me choose the channel.

Everything in the app is read only apart from the release button and the Slack post. Session statuses are PENDING, RUNNING, ERROR, TIMED_OUT and COMPLETED, so use those exact values when filtering. Someone without a Browserbase login should be able to open this and understand where the money is going.