Observability

Gibson treats observability as a first-class feature, not a bolt-on. Every mission emits a structured event stream. Gibson traces every LLM call with the full prompt and counts its tokens. The audit log records every permission decision. Every checkpoint is a resumption point that you can replay from.

This page is the operator's tour. It shows where each piece lives in the dashboard, what it captures, and how to use it day-to-day.

Mission monitoring

The mission detail page is the primary view. From the dashboard's Missions section, open any run.

Panel	What you see
Overview	Mission name, status, target, start/end times, duration, total cost, total tokens.
DAG	The mission graph with each node colored by status. Click a node to see its inputs, outputs, and timing.
Events	The lifecycle event stream in real time, node.started, finding.submitted, secret.read, mission.completed.
Findings	Findings produced during this run, with severity and triage status.
Discoveries	Knowledge-graph entities ingested during the run, grouped by type.
Logs	Per-component logs (agent stdout/stderr, tool error output).
Secrets accessed	Which credentials plugins read during the run, names only, never values.
LLM trace	Every LLM call: prompt, response, tokens, latency, cost.

Mission runs persist indefinitely by default. To override this, go to Settings → Retention.

Tracing LLM calls

Every Harness.Complete call, and its related calls, lands in Gibson Traces, your tenant's trace explorer.

Each trace captures:

• the full prompt as sent to the model
• the full response
• input + output token counts
• latency and provider-reported cost
• the slot the call used and the model it resolved to
• the agent execution and mission node it came from

To see a mission's trace stream, open the LLM trace tab on its mission detail page.

The trace explorer supports search, filters, and dataset-style collections. These help when you evaluate prompt changes, run regression tests, or share traces with your team.

Metrics

The Metrics dashboard shows operational counters and histograms. Built-in views:

View	Shows
LLM usage	Tokens (input/output) and cost by model, slot, agent, time window.
Mission throughput	Active missions, completion rate, average duration.
Tool calls	Calls per tool, p50/p95 latency, error rate.
Agent activity	Iterations, delegation depth, finding submission rate.
Findings rate	Findings per day by severity.
Plugin health	Plugin status, restart count, secret cache hit rate.
Secrets backend	Per-broker latency and error rate for your tenant's configured backends.

You can also export Prometheus-compatible metrics from your tenant under Settings → Metrics export. Your own monitoring stack can then scrape them.

Audit log

Settings → Audit log is the durable record of every meaningful action in your tenant:

Category	Examples
Identity	user.invite, user.remove, component.enroll, component.disable
Permissions	grant.write, grant.delete, authz.deny
Secrets	secret.create, secret.read, secret.update, secret.delete, secret.bind, secret.config_set
Missions	mission.create, mission.run, mission.pause, mission.cancel, mission.replay
Plugins	plugin.register, plugin.invoke, plugin.rotate-restart
Findings	finding.create, finding.status_change, finding.export

Filter by actor, action, target, outcome, or date range. Export filtered views as CSV or JSON for compliance evidence.

Credential values are never in the audit log. The log holds only secret names and the requesting identity.

Replay

Replay lets you ask "what if?" without re-running the whole mission. On a mission detail page, click Replay from checkpoint.

Choice	Effect
Replay	Re-runs the chosen checkpoint forward with the same inputs. Useful for retrying flaky steps.
Replay with override	Re-runs forward with an override, different prompt, different LLM slot, different tool variant. Useful for evaluating changes.

Gibson stores each replay as its own mission run. The mission detail page links it to the original under Replays of. The audit log records who triggered the replay and which values they overrode.

Common uses:

• The triage agent flagged the wrong thing. Fix the prompt, then replay from the triage node.
• A tool was flaky. Replay only that node.
• Compare two LLM slots on the same prior mission. Replay it twice, once with each slot binding.
• Verify a fix. Re-run the discovery step against the patched target.

Alerts

Configure alert destinations under Settings → Integrations → Alerts:

Trigger	Common uses
New finding above severity X	Slack/email on every high or critical.
Mission failed	PagerDuty on a production mission failure.
Permission denial spike	Notify when authz denials cross a threshold (often a misconfig).
LLM cost over budget	Daily digest if cost exceeds a threshold.
Plugin restarted unexpectedly	Notify on restart rotations or crash-restarts.
Secret rotated	Audit confirmation to a security mailbox.

Each destination has its own filter. You get only the alerts that you asked for.

Per-component status

The dashboard's Components section shows enrolled agents, tools, and plugins with their current status, last contact time, and recent mission activity. From a component detail page you can:

• view the recent missions it participated in
• view its current grants and any deny entries
• view its logs (where Gibson collects them)
• disable it temporarily without unenrolling it
• rotate its credential

Health checks

Plugins and tools expose a Health() callback. Gibson polls it on the interval that the plugin manifest declares, or on the SDK default for tools. Health rolls up into the Components view. It also rolls up into the mission detail page when a node is dispatched against an unhealthy component.

Best practices

• Set a cost budget (Settings → LLM budget) for each tenant. When a tenant exceeds the budget, Gibson pauses new mission dispatch instead of a silent overspend.
• Pin a "missions failed" alert to your team channel. Once failed missions are in the log, people no longer notice them.
• Use trace datasets when you iterate on prompts. Capture a few representative mission traces. Then re-run the prompt against the dataset and compare the outputs before you deploy.
• Audit-log retention is configurable per tenant. The default is two years. Most compliance frameworks require at least 12 months.

Related

• Missions covers the lifecycle and the event stream that replay draws on.
• Findings covers alerts on findings and severity-based routing.
• Secrets management covers secret.read events in the audit log and rotation flows.
• Roles & permissions explains how every authz decision lands in the audit log.