Monitor executions

Three views, each answering a different question: are my executors healthy right now, how is this one host doing, and what has run.

Live monitoring

Remote Executors → Monitoring is the dashboard, subtitled “Real-time executor health and execution activity”. It updates by itself — a Live indicator in the top right shows the stream is connected, Disconnected means it isn’t and the numbers may be stale.

The Monitoring dashboard with six stat cards, the executor grid and recent executions

Six counters across the top:

Card	What it counts
Total	Every executor in the project.
Online	Connected and taking work.
Degraded	Connected but under strain.
Offline	Not currently connected.
Active Runs	Executions in flight across all executors right now.
Queued	Executions waiting for a free slot.

Below them, every executor as a card with its live metrics, and a Recent Executions table.

Queued climbing while Active Runs sits flat is the signal that an executor is saturated — work is arriving faster than it can run it. Either raise CONCURRENCY on that host, or add another executor.

Per-executor metrics

The Metrics tab on an executor’s detail page shows what its most recent heartbeat reported.

The Metrics tab showing CPU and memory usage, active and queued executions, total executions, and the Additional Metrics list

Five headline cards:

Card	Notes
CPU Usage	Host CPU. Highlighted amber above 90%.
Memory Usage	Host memory. Highlighted amber above 90%.
Active Executions	Running on this executor right now.
Queued Executions	Waiting for a free slot.
Total Executions	Since the agent started.

Below them, Additional Metrics lists everything else the agent reported, under its raw name:

Key	Meaning
`memory_used_mb` · `memory_total_mb`	Host memory in use, and total. These won’t divide out to exactly the Memory Usage percentage — that card uses the operating system’s own memory-pressure figure, which discounts cache the OS can reclaim on demand.
`uptime_seconds`	How long the agent has been running since it last started.
`total_errors`	Failed executions since the agent started.

uptime_seconds is the useful one when an executor is behaving oddly — a value far lower than you expect means the agent restarted, which is worth knowing before you go looking for anything subtler.

Sustained CPU above 90% moves the executor to Degraded. It keeps taking work, and returns to Online on its own once CPU comes back down.

Before the first heartbeat the tab reads “Metrics will appear after the executor sends its first heartbeat”. Heartbeats arrive every 20 seconds by default.

Execution history

The Executions tab on an executor’s detail page lists what that executor has run — status, type, duration and start time, most recent first. Refresh re-reads the list; it doesn’t stream.

The Executions tab listing recent executions with the status filters and one row expanded

Filter by status with All, Running, Completed, Failed and Queued. Click any row to expand it for the error message and identifiers — that expanded view is where a failure actually explains itself, so it’s the first place to go when a step failed and you want to know why.

Executions appear here whether they came from an agent run or from testing a tool, so it doubles as confirmation that a tool you just pointed at this executor really went there.

💡

Testing a tool with Execution Location: Remote produces a real execution record here, the same as a production run. It’s the quickest way to confirm an executor can reach something without building an agent first.

What to look at when something’s wrong

An agent step failed and you suspect the executor — open that executor’s Executions tab, filter to Failed, expand the row. The error message is the executor’s own.
Everything is slow — check Queued on the dashboard. Work arriving faster than the executor can run it is the usual cause.
Work isn’t reaching an executor at all — nothing will appear in the Executions tab, because a step that never dispatched leaves no record. Check the executor is Online and the node or tool is actually set to Remote; Run work on an executor covers how the decision is made.
Which executor ran it? — the dashboard’s Recent Executions table spans all executors, so start there when you don’t yet know which host to open.

Common issues

The Live indicator says Disconnected — the browser lost the update stream. Reload the page.
No executions listed after running an agent — the step ran locally. Confirm the node or tool is set to Remote and an executor was Online at the time.
Metrics are empty on a connected executor — wait for a heartbeat; they arrive every 20 seconds.
Duration looks longer than the work took — duration covers dispatch, queue time on the executor, and execution. A busy executor inflates it; compare against Queued.

Troubleshooting — when an executor won’t connect at all.