Documentation / Conception / Guides pratiques / Monitor executions

Monitor executions

The Executions view is where you watch workflows run: a live list of every run, the timeline of a selected run, the patient record it touched, and a composer to emit an event by hand. It merges what used to be the console and the monitoring page into one screen (apps/config-plane/app/executions/ExecutionsView.tsx; the run list, timeline, and patient panel are the shared components in apps/config-plane/lib/runs.tsx). This recipe walks the four things you do there.

Prerequisites

  • A running Meridian instance with the config plane open — see Your first instance.
  • At least one deployed workflow. Runs are created either by an event source or by the composer below.
  • To resolve a validation, a workflow with a human-validation node — see Add human validation.

Read the run list

The left pane lists all runs, newest first, and in live mode refreshes itself every 2 seconds — a new run (from an event source or the composer) appears without a reload.

  1. Read the pane header: Runs · N is the total, and a to resolve tag counts runs currently suspended (waiting on a validation).
  2. Scan each row. It shows the workflow name, then a colored status LED with the raw status, the run's subject ids (one per context kind present in the event — e.g. the patient), and the run's creation time. Status is one of running, completed, suspended, failed, or pending; anything else renders as an unknown state.
  3. Click a row to select it. The center pane loads that run's detail; if the run is unreadable (for example, a run recorded before a Restate service rename) the center pane shows the error instead of stale detail.

The most recent run is auto-selected on first load. An empty list means no run has been created yet.

Read a run's timeline

Selecting a run fills the center pane. The header badge repeats the status, workflow name, subject ids, creation time, and the (truncated) run id. Below it, under Workflow flow, is the timeline.

  1. Read the timeline top to bottom — it is the engine's observations in execution order, one row per node. Each row has an index, a status icon, the node id, and a one-line summary of its outputs:
    • ✓ — node ran (done)
    • ⤼ — node was skipped; the summary gives the reason
    • ✍ — a validation on this node was resolved; the summary names the decision and who made it
    • ⏸ — this node is the one awaiting a decision right now
    • a trailing ↺ next to a node name marks a step that was replayed on resume (durable-execution replay — see Why durable execution)
  2. Click any row to expand it. You get the node's inputs, its config, and its outputs. On the trigger row, the expansion shows the raw event received that started the run.
  3. In live mode the detail keeps refreshing every 2 seconds while the run is running or suspended, so a suspended run flips to its resolved state in place once someone decides.

Runs that failed too early to record observations (and very old runs) fall back to the raw step trace instead of the node timeline.

Resolve a pending validation

When the selected run is suspended, a validation block appears above the timeline with the question title and the payload to judge.

  1. Read the payload, then click Accept or Reject. From anywhere on the page (except while typing in a field or with the composer open) the keyboard shortcuts A and R do the same.
  2. The decision posts to the run, the timeline updates, and the run list refreshes.

That is the operator side of the two-level validation model; for the full picture of resolving and what happens next, see Run and resolve and Two-level validation.

Inspect the patient record

The right pane shows the live patient record for the selected run's patient subject — whatever the patient adapter holds now, in-memory or a real FHIR warehouse (served by GET /api/records/patient/:id).

  1. Read the header line for demographics (name, sex, age, birth date, a deceased tag when applicable).
  2. Scroll the sections: medications, allergies (a high-criticality allergy is flagged critical), procedures, the most recent observations (up to eight), conditions, and notifications emitted for this patient.

The pane is empty (—) when the run has no patient subject or the record can't be fetched.

Emit an event

Use the composer to trigger a run by hand — to test a workflow end to end without wiring an event source.

  1. Click Emit event in the top bar. The composer opens in the center pane.
  2. Pick the target workflow from the dropdown. A ⚠ next to a name means that workflow currently fails static validation (validate it first). The note beside the dropdown states the workflow's trigger type.
  3. Edit the event payload. It is prefilled with the workflow's example event; keep it valid JSON matching the trigger's event type.
  4. Click Send event. The composer posts the payload (tagged with the target workflow), refreshes the run list, and selects the run it just created so you land on its timeline. Escape or Cancel closes the composer without sending.

Emitting here and receiving from a source are the same mechanism — both create a run from an event. To make events arrive automatically, see Connect an event source and The open event model.

Freeze the view with live mode

The Live toggle in the top bar controls auto-refresh.

  1. Leave it on (Live on) to keep the list and the open run polling every 2 seconds — the default for watching activity as it happens.
  2. Turn it off (Live off) to freeze the current snapshot while you read a timeline without it moving under you. The status bar reads frozen and stops updating the last-sync time.

The status bar at the bottom always shows live/frozen, the run count, the count of runs awaiting a decision, and the time of the last sync.

75 documents8 sectionssource : /docs · généré au build