Skip to docs content
Browse documentation
On this page

Activity

Where to see what ran and what failed: the Runs page, the minion.runs.* capabilities, and how to triage or react to errors.

When a job fails, a package app crashes, or a webhook delivery rejects, Minion keeps a run record so you (and your agent) can see what happened.

Waiting is the current-state queue of things only you can clear. Runs are history; they do not replace Waiting.

Where to look

Open /app/runs while signed in. The page lists runs newest first, with views for:

  • All runs
  • Open failures: errors nobody has triaged
  • Ignored and Resolved: errors someone has triaged

A package filter narrows the list to one package, or to ad hoc runs with no saved package. Open a run to see its captured log lines, the error and stack, and any triage note. Failed runs have a triage form on the list and the detail page.

Ignored and resolved error runs stay in history but are hidden from the default error views so soft-failures and already-fixed noise do not clutter triage.

From /app/jobs , each job's recent runs link into the same detail view.

Ask your agent

The runs domain reads and triages the same data:

  • minion.runs.summary(): "is anything broken?" Totals since a time (default the last 24 hours), open errors, ignored and resolved counts, and a per-source breakdown.
  • minion.runs.list({ status?, source?, errorTriage?, since?, packageId?, limit? }): filtered history, newest first. source is execute, job, webhook, event or app. By default runs marked ignored or resolved are hidden; pass errorTriage: "all" to see everything.
  • minion.runs.get({ id }): one run plus its log lines, error, stack, result and triage fields.
  • minion.runs.update({ id, errorTriage, note? }): mark an error run ignored or resolved (or open to clear triage), with an optional note. It is non-destructive; error details stay intact.

Search for "runs", "failures", "ignore this error", or "why did my job stop working" if your host does not surface those names yet.

Execute calls that outlive your request

If an execute call times out on your side, the run keeps going. Poll minion.runs.get({ id: runId }) until status is no longer running, or repeat the call with the same idempotencyKey to get the stored result back. Reusing an idempotency key never runs the code twice. See Execute and workflows .

What is stored

Payload bodies for inbound webhooks are never stored, only delivery metadata and logs. Packages' exports and keyed execute runs keep a size-capped copy of the returned value, and secret values are redacted from logs and errors.

React to failures from a package

Packages can subscribe to the run.error.recorded topic in package.json#minion.subscriptions. When a run in your organization finishes failed or timed out, Minion dispatches a metadata-only event (runId, source, status, a short error, finishedAt and a runUrl link to the run) to matching handlers. Use that to email yourself, write to a sheet, or otherwise follow up. See Packages and the package subscriptions guide .

Related