Mogplex Docs
Web App

Observability

Inspect Mogplex run health, pressure, sandbox time, model-call activity, tool calls, and estimated cost across CLI, cloud, and automation.

Observability is the runtime view for Mogplex work that has already started.

This is where you answer questions like:

  • did the work actually run?
  • is the system under pressure, stuck, or failing?
  • which model call or tool call caused the problem?
  • is cost coming from the CLI, hosted work, or automation?

The page has two jobs

Observability is easiest to use when you treat it as two layers:

  • summary cards tell you whether the overall system looks healthy
  • Activity tells you what happened on individual calls

Read the cards first when you want the shape of the problem. Open Activity rows when you want the actual story.

What the summary cards show

The summary area combines three kinds of signal.

Job health

  • total runs
  • currently running runs
  • stale pending runs
  • failed runs in the last 24 hours
  • repaired runs in the last 24 hours
  • 24-hour run success rate

Dispatch pressure and queue health

  • suppressed starts in the last 24 hours
  • deferred starts in the last 24 hours
  • start failures in the last 24 hours
  • oldest pending age

Usage and spend

  • total calls
  • calls today
  • tokens used
  • estimated cost
  • average call duration
  • call success rate
  • total sandbox time plus active and total sandbox counts

That means Observability can tell you whether the problem is broad, isolated, expensive, or stuck before you inspect a single detailed row.

What the Activity table shows

The main table is call-level, not job-level.

Each row shows:

  • When the call started
  • Surface: Live, CLI, Cloud, or Automation
  • Who: model plus call type
  • Where: repo context when available
  • IO: input and output token counts
  • Cost
  • Duration
  • Result

Current table filters are:

  • surface
  • status

Repo and sandbox filters are also supported through deep links from elsewhere in the app, such as the sandbox management page or repo-specific drilldowns.

What the surface badges mean

The surface badge is derived from the call record:

  • Live means the call is still pending or streaming
  • CLI means it came from a runtime command in the local CLI path
  • Cloud means it ran outside a job-backed automation
  • Automation means it is attached to a job run

That split is the quickest way to answer whether failures or spend are coming from local work, hosted work, or automation.

Expand a row when you need the real story

Opening a call row exposes the details Mogplex captured for that call, which can include:

  • a GitHub deep link when the source metadata maps back to a PR, issue, or related event
  • managed sandbox access details, optional linked Vercel project metadata, sandbox record ID, preview URL, and runtime ID
  • a shortcut to open sandbox health directly
  • runtime command ID when the call came from the CLI path
  • the error string, if the call failed
  • an event timeline
  • tool calls with captured inputs and outputs
  • raw metadata for deeper inspection

This is the part of the app that answers questions like “what tool did the agent call?”, “which sandbox did this run touch?”, and “what GitHub object did this call come from?”

Practical workflows

A sandbox-backed run looks unhealthy

  1. Open the relevant call row.
  2. Inspect managed sandbox access and preview metadata.
  3. Jump straight to sandbox health from the row instead of debugging the model call in isolation.

Cost or token usage jumped unexpectedly

  1. Read the summary cards first to confirm whether this is broad or isolated.
  2. Filter Activity by surface or status.
  3. Inspect the most expensive or highest-token calls and look at tool usage in expanded rows.

A trigger, assignment, or automation seems quiet

  1. Check whether the summary cards show runs, stale pending work, suppression, or start failures.
  2. If no relevant call appears in Activity, go back to the source surface: Triggers, Assignments, or Automations.

What Observability does not own

Observability is for inspection after work has queued or started.

Creation, enable or disable state, and routing changes still belong to the source surfaces:

Edit on GitHub

On this page