Monitor and control runs

Operational execution inspection belongs under mn run. Keep the run ID returned by mn blueprint run or mn job start; the job ID identifies the durable definition, while the run ID identifies one execution.

Runtime and run state

Start with aggregate runtime health:

mn runtime status

Use deep diagnostics only when the aggregate status needs investigation:

mn runtime doctor

List and inspect executions:

mn run list
mn run list --job <job-id>
mn run show <run-id>
mn run watch <run-id>

Ctrl+C intentionally detaches from watch; it does not cancel the run.

Logs, events, and results

mn run logs <run-id> --channel logs
mn run logs <run-id> --channel events
mn run logs <run-id> --channel all --follow
mn run resources <run-id>
mn run result <run-id>

run result writes under $MN_HOME/outputs/<run-id> unless --output is supplied. Preserve logs, events, artifacts, timestamps, and sanitized configuration when reporting a failure.

Blueprint report generation stays under blueprint:

mn blueprint export <run-id> --format markdown --output report.md

Control

mn run pause <run-id>
mn run resume <run-id>
mn run cancel <run-id>

Cancellation stops runtime work but cannot reverse an external action already performed by a worker. Review side-effecting adapters and idempotency before launch.

Deleting a terminal run removes stored run data. Preserve needed evidence first; deletion is not a way to stop active work.

mn run delete <terminal-run-id> --yes

Human collaboration

mn run human list <run-id> --pending
mn run human respond <run-id> <request-id> --decision approve
mn run human ack <run-id> <notice-id>

See Troubleshooting for Redis, OpenShell, model, API, and cluster-specific diagnostics.