# Morning triage board for your Kernel browser agent runs

> See every overnight browser run that failed, watch the replay, and let an agent tell you whether the site changed or your own script broke.

- Workflow type: app
- Services: Kernel, Linear, Slack Bot
- Categories: Engineering
- Published: 2026-08-31

## What it does

- Opens on a board of your recent cloud browser runs grouped by app and action, with status, duration and the error message on every row.
- Shows a seven day failure rate trend for each app, plus a side panel of sessions still running so you can spot jobs that hung.
- Click any run to watch its session replay next to the session details, then re-run it, kill a stuck session, file a Linear bug or post a shift handoff note to Slack.
- A Diagnose button sends an agent to retrace the failing step in a fresh browser and report back in plain English whether the site changed, you hit a login wall or your script broke.

## What you'll need

- A Kernel account with the browser agents you want to watch already running there
- A Linear workspace where bugs get filed
- A Slack workspace for shift handoff notes

## Prompt

Build me an internal app my team opens every morning to triage the browser agent runs we run on Kernel. The audience is whoever is on call for our fleet of browser agents, and the question the app has to answer in the first minute is: what broke overnight, and is it our bug or theirs.

The main view is a run board. Use Kernel's List Invocations to pull recent invocations and group the rows by application and action, using List Deployments to resolve friendly app and action names. Each row shows the run status, how long it took, the error text if it failed, and its current triage state. Let me filter by status, app, action and time window, and default the board to the last 24 hours with failures sorted to the top.

Above the board, show a failure rate trend per app over the last seven days, computed from the same invocation history, so I can see whether an app has been quietly degrading rather than failing all at once. Along the side, keep a panel of sessions that are still running, from List Browser Sessions filtered by status, with how long each one has been alive, so we can spot jobs that hung and are holding a browser slot open.

Clicking a run opens a detail pane. Pull the run's own record with Get Invocation for status, output and error, and use List Invocation Browsers to tie the run to the browser session it created. Show the session metadata from Get Browser Session next to the session replay: call List Browser Replays for that session and Download Browser Replay to play the recording inline.

One caveat to handle honestly rather than fake: Capture Browser Screenshot only works against a session that is still alive, so there is no way to grab a final screenshot of a run that already ended. For sessions still running, show a fresh live frame. For finished runs, show the screenshots the diagnose agent saved during its retrace, and treat the replay video as the primary artifact. Do not build a UI slot that implies we can screenshot a dead session.

From a row or the detail pane I can act. Re-run a failed job with Invoke Action, reusing the same app, action and payload, and link the new run back to the one it replaces so the board shows the pair. Kill a hung session with Delete Browser Session. File a bug in Linear with Create Issue, then Add Link to Issue so the replay link and the run link ride along on the issue. Post a shift handoff note to Slack with Send a Message, summarizing what failed overnight, what is still open, and what was already handled.

Every run also gets a Diagnose this run button that kicks off a background agent. The agent reads the invocation and the session details, then opens a fresh Kernel browser with Create Browser Session and retraces the failing step using Execute Batch Computer Actions and Capture Browser Screenshot, saving the screenshots it takes so the detail pane can show them. It then writes a plain English root cause back into the app and commits to one of three verdicts: the site changed, we hit a login wall, or our own script broke, with the evidence it saw for that call. Before it drafts anything it runs Search Issues in Linear so we never log the same broken selector twice, and when it finds a match it links the existing issue instead of drafting a new one. When it does draft, the Linear issue stays a draft inside the app for a human to confirm and file rather than being filed automatically. Have the agent delete the browser session it created when it finishes so a diagnosis never leaves a session running.

Keep a triage state per run that persists: new, investigating, ignored, filed. Store it alongside the diagnosis text, any drafted issue, the linked Linear issue URL once filed, and who changed the state and when, so the next person on shift sees what has already been handled instead of re-diagnosing the same failure. Show that state on every row and let me change it inline from the board.

One more thing that keeps the board readable: when several runs of the same app and action failed with the same error text, group them into a single row with a count so one incident does not look like twenty separate problems. Triage state and diagnosis then apply to the group.

## How to customize

- Change the default time window on the board and which apps or actions sort to the top.
- Point the shift handoff note at whichever Slack channel your on call team watches, and set what it includes.
- Rename the triage states to match how your team works, or change which Linear team new bugs get filed into.

## FAQ

### Does it file a bug for every failure automatically?

No. The agent writes up a root cause and drafts the issue, but a person confirms it before anything reaches Linear. It also searches your existing issues first, so a selector that broke last week gets linked to the bug you already have instead of filed twice.

### Will it re-run failed jobs on its own?

No. Re-running is a button you press on a row. The board never retries anything by itself, and a re-run is linked back to the run it replaces so you can see the pair.

### Can I see runs that already finished, or only ones happening now?

Both. Finished runs are the point of the board, and each one plays back its recorded session so you can watch exactly what the agent did before it broke. Sessions still running get their own side panel with how long they have been alive.

### Does diagnosing a run cost extra browser time?

It opens one fresh browser to retrace the failing step, then closes it when it is done, so a diagnosis does not leave a session running or eat a slot in the background.

### What happens if two people triage the same run?

Triage state is shared across the team and persists, so a run marked investigating or ignored shows that way for everyone, along with who changed it and when.

Use this prompt in General Input: https://www.generalinput.com/prompts/morning-triage-board-for-your-kernel-browser-agent-runs