Log in Create workspace
Skip to content

Platform

Operator observability console

Investigate a trace, reproduce suitable work with a replay, and coordinate ownership and remediation on the resulting failure group. Browser screens and operator REST work with the same workspace evidence.

API docs
Browse docs
On this page

Start here

Turn traces into an investigation workflow: start from a preset, inspect a run, bind a replay target when safe, and keep remediation ownership with the failure group.

Before you begin

  • A signed-in workspace operator with access to trace and failure-group screens
  • An ingested trace plus a safe replay target and clear incident owner when needed

Put it into practice

  1. Narrow the evidence

    Open /app/traces or the explorer presets for live, errored, unbound, or replayable work. Select the trace that best represents the issue.

  2. Inspect or reproduce

    Review trace events and payloads, then bind an appropriate target and submit a replay only when reproducing the action is safe. Follow its generated timeline separately from the source.

  3. Coordinate remediation

    Use failure-group status, assignee, incident owner, escalation details, playbook URL, notes, and remediation metadata to make the next action explicit.

What success looks like

An operator can identify the failing execution, compare a replay with its source when needed, and leave the failure group with a clear owner, status, and remediation trail.

01 Screens

reference
Path What it does
/app/traces Workspace trace list
/app/traces/explorer Live, Errored, Unbound, and Replayable presets
/app/traces/:id Bind a target and submit a replay
/app/replays/:id Source vs generated timeline; cancel a queued or running replay
/app/failure_groups/:id Collaboration plus an eval-draft action

02 Failure-group PATCH beyond status

details

Collaboration metadata

In addition to status, assignee, and collaboration_note, PATCH accepts incident_owner, playbook_url, escalation_level, escalation_note, and remediation_* fields. Those keys are merged into collaboration metadata.

03 Gateway replays are re-authorized

details

Requirements and run-time checks

A replay of a gateway action needs an active service agent recorded on the source trace; without one the request is refused with a validation error asking you to repair the service agent. source_context_override may only fill in the connector, action, payload, or service agent the source trace did not record. From a browser session it is accepted only from workspace owners and admins; machine credentials need gateway:execute, may replay only their own agent's actions (an override cannot name another agent), and are not subject to the admin check. When the replay runs it passes the freeze check, the workspace gate, and the gateway authorizer again, and only an allowed decision executes: a freeze fails it with gateway_frozen, a paused or archived workspace with workspace_paused or workspace_archived, a denied decision with authorization_denied and a requires-approval decision with requires_approval (both carry decision_path), and a workflow target repointed after the request fails with replay_path_changed -- request the replay again.

Troubleshooting

A trace is not replayable
Use the explorer's replayable preset and check that a compatible target can be bound. Do not force a replay for evidence that lacks the required context.
A replay appears stuck
Open /app/replays/:id to inspect its timeline and status. Cancel only queued or running work, then use failure details rather than starting duplicate replays blindly.
PATCH metadata seems missing from the reference
The failure-group PATCH also accepts the collaboration and remediation fields listed below; they are merged into collaboration metadata.

Where to go next

see also
Operator - Observability Operator REST Traces Machine ingest