# Browser automation session console with live view and replay > See every browser automation running right now, watch a failed overnight run back as video, and stop a runaway session in one click. - Workflow type: app - Services: Anchor Browser, Google Sheets - Categories: Engineering, Operations - Published: 2026-08-14 ## What it does - Lists every browser session running right now, with how long it has been going and a link to watch it live. - Keeps a searchable history of past runs you can filter by status and date, so you can find last night's failures in seconds. - Opens any run to show the pages it visited and plays back a video recording of what the browser actually did. - Reports how many runs happen per day, how long they usually take, and how often they fail, with an optional export to a Google Sheet. ## What you'll need - An Anchor Browser account and its API key, which the console uses to read and manage your sessions. - At least one browser automation that has already run, so there is history to look at. - Optional: a Google account and a spreadsheet, only if you want to export the daily totals for charting. ## Prompt I want an internal console that the team running our browser automations keeps open all day, so they can see what is running right now and work out what went wrong overnight without digging through logs. Build it as a single wide page: a live section at the top, a session history table below it, a usage panel, and a detail panel that opens when any row is clicked. The top of the page is a Live Sessions section backed by the Anchor Browser List All Sessions Status operation. Show one row per active session with the session id, its status, when it started, and an elapsed time counter that ticks up while the page is open. Each row links to that session's live view URL so anyone can watch that browser in real time in a new tab. Refresh this section automatically every fifteen seconds while the page is open, and include a manual refresh button plus a last updated timestamp so people can tell whether they are looking at stale data. Every active row has an End Browser Session button that terminates just that session using End Browser Session, for when a single run has gone into a loop. At the top of the section there is an End All Sessions button wired to End All Sessions. That operation kills every active session on the whole API key, so it must be guarded: open a confirmation dialog that states how many sessions are about to be terminated and requires the user to type END before the confirm button becomes active. After either action, refresh the live list and report what happened. Below the live section is a Session History table fed by List Sessions History Page. Columns: session id, status, start time, end time, and duration. Give it a status filter and a date range filter, both passed through to that operation's own filtering and sorting so the server does the work, plus paging controls that walk through the pages it returns. Default it to the last 24 hours sorted newest first, since the first question every morning is what happened overnight, and add a one-click failures only shortcut. Clicking any row, live or historical, opens a detail panel. At the top, full session information from Get Browser Session laid out as readable labelled fields rather than raw JSON. Below that, the pages that session visited from Get Browser Session Pages, in visit order with URL and title. Then the recordings: call List Session Recordings to get the recordings available for that session and Get Session Recording to load the primary recording file, and render it in a video player with normal transport controls so a failed run can be watched back and scrubbed frame by frame instead of guessed at from logs. If a session has no recording, say so plainly instead of showing a broken player. Each recording listed in the detail panel has a Delete button wired to Delete Session Recording, for clearing out old recordings that are just taking up space. Confirm before deleting, and remove the recording from the list once the call succeeds. Add a Usage panel derived entirely from session history. Anchor Browser exposes no billing or credits operation, so this panel must never show a credit balance, a spend figure, or anything resembling a bill. Pull the history for the selected date range with List Sessions History Page and compute: runs per day as a small bar chart, average session duration, longest session duration, and failure rate as the percentage of sessions in the range that ended in a failed state. Show the raw counts the numbers were computed from so nobody mistakes them for billing figures. The usage panel has an optional Export to Google Sheets button. It sends the daily totals for the selected range, one row per day with the date, run count, average duration, longest duration, and failure rate, into a spreadsheet the user picks, using the Google Sheets Append Values operation so each export adds to the bottom of the sheet instead of overwriting earlier exports. Write a header row only when the target sheet is empty. This is opt-in for anyone who wants to chart the trend over time, and the console must work fine without it. Remember each user's last used filters, meaning status, date range, and the failures only toggle, along with their chosen export spreadsheet, so the console opens where they left it. The console is shared by the whole team, so record every destructive action, ending one session, ending all sessions, or deleting a recording, in a small in-app activity log with the action, the session id, the time, and who triggered it, so a fleet that someone killed at 2am is not a mystery in the morning. Handle the obvious failure modes plainly. No active sessions is a normal state and should read as nothing running rather than an error. A session id that has already ended returns not found from the detail operations, so show a short explanatory message instead of an error dump. If the history request fails, keep the last loaded rows on screen and flag that the refresh failed. ## How to customize - Change the default time window and how often the live list refreshes itself. - Adjust which columns appear in the history table and what counts as a failed run. - Turn the spreadsheet export on or off, or point it at a different sheet. ## FAQ ### Can I stop a browser session that is stuck? Yes. Every running session has its own stop button, and there is a separate button that stops everything at once. Because stopping everything affects every automation on the account, the console makes you confirm before it acts. ### Does this show how many credits I have left? No. Anchor Browser does not make billing or credit information available to other apps, so the console cannot show a balance or a spend figure. The usage panel is worked out from your own session history instead: runs per day, typical and longest run times, and failure rate. ### Can I watch a run that already finished? Yes, as long as a recording was kept for it. Open the run from the history table and the recording plays inside the console, so you can scrub back to the moment it went wrong instead of guessing from logs. ### Will the whole team see the same information? Yes. The console reads from your Anchor Browser account, so everyone looking at it sees the same live sessions and the same history. Your own filter choices are remembered for you. ### Do I need the Google Sheets export? No. It is optional and only there if you want to chart usage over time. Everything else in the console works without connecting a spreadsheet. Use this prompt in General Input: https://www.generalinput.com/prompts/browser-automation-session-console-with-live-view-and-replay