Use the diagnostics console

When an agent misbehaves, the question is what this deployment just did. Logs answer that badly: they are a firehose with no shape, and the thing you need is usually a relationship between two facts that scrolled past ten minutes apart.

The console is that view. It reads the diagnostics API and nothing else, so it shows what the server actually recorded rather than a second model of it.

Turn it on

There are two switches, and they are separate on purpose:

AXL_DIAGNOSTICS_ENABLED=true    # the server records, and serves, diagnostics
AXL_CONSOLE=embedded            # this binary also serves the console at /console

AXL_CONSOLE accepts only embedded. Anything else - including a typo - leaves it off, because a value the build does not understand is not a reason to expose a surface nobody asked for.

With both set, the console is at http://<server>/console, version-locked to the API it reads because the same binary serves both.

Open it

axl console

The CLI already holds a credential the console would otherwise ask you to paste, so it hands one over and opens a browser. The token rides in the URL fragment, never the query - no browser sends a fragment to a server, so it stays out of access logs, proxy traces, and Referer headers. The console reads it once, stores it, and strips the fragment from the address bar, replacing rather than pushing the history entry, so a screenshot or a shared link carries nothing.

Reading the boards needs the diagnostics:read scope, and seeing every principal's activity rather than only your own needs the platform admin role.

Other ways in:

axl console --profile prod    # a different deployment
axl console --print           # print the URL instead of opening it, for a remote shell
axl console --no-token        # hand over the server, let the console ask for its own

Opened any other way, the sign in chip in the top bar takes a pasted token. The same chip switches between servers, so one console can watch several.

What the boards are for

The left rail is grouped by the question you are asking.

Live is the one to start on. Every counter drills into the records behind it, so a number that looks wrong is one click from the rows that produced it.

Smoke runs named rules over the live boards and raises a finding that is held until it stops being true - so a fault that appeared for four seconds at 3am is still on the board at 9am. Its second panel is boot posture, which is deliberately not alerts: pii_vault_key_present: off means you did not configure it, not that something broke.

Reading a run

Runs holds the in-flight loops and a bounded ring of the ones that finished. Each finished row carries its ending, wall time, iterations, tokens in and out, cost, and guard trips.

Some columns say not measured rather than 0. That is the point: an unmeasured quantity and a measured zero are different facts, and a board that renders the first as the second is misrepresents the data. Anywhere the console cannot answer, it says so.

The ring is per-instance and in memory, so a restart empties it. Durable history - workflow runs, tasks, sessions - survives, because that lives in Redis.

Watching a workflow

Workflows lists runs, and selecting one draws its graph: every node with its state, beside the .axg source it was compiled from. Clicking a node jumps to the construct it came from, showing why it took that branch.

When the console is empty

An empty board is ambiguous, so the console works to disambiguate it:

• "Runtime diagnostics are not enabled on this deployment" - AXL_DIAGNOSTICS_ENABLED is off. The server is fine; it is recording nothing.
• A narrowed reader - the top bar reports it. Your token can reach some boards and not others, so what you see is a smaller truth rather than a quieter deployment.
• nothing is wrong right now - the rules ran and found nothing. Distinct from a board that could not read its ground, which says that instead.

Keyboard

Next

• Observe runs - traces and metrics, for the questions that outlive a live view.
• axl events tail - the same feed on a terminal, filtered.
• Troubleshoot a deployment - when the console says something is wrong.
• Diagnostics internals - how the records are made.