Monitor and Control a Job
Inspect MirrorNeuron job state, events, and blueprint run artifacts.
Monitor and Control a Job
Use this guide after a workflow has been submitted and you have its job ID. You will inspect runtime state, inspect blueprint artifacts, cancel work safely, and collect evidence for troubleshooting.
Before you begin
- Know the
<job_id>returned when the workflow was submitted. - Keep the
<run_id>when the launch produced one; it identifies blueprint run-store records. - Run
mn runtime healthfirst if job commands cannot reach the runtime.
Inspect a job
List recent jobs when you do not know the ID:
mn job listRead the current state and stream events:
mn job status <job_id>
mn job monitor <job_id>Replace <job_id> with the submitted job identifier. A terminal state is completed, failed, or cancelled. It means runtime execution reached an end state; inspect artifacts and warnings before treating a domain result as correct.
Inspect blueprint artifacts
When you have a run ID, inspect its run-store records separately from job state:
mn blueprint logs <run_id>
mn blueprint tail <run_id>
mn blueprint export <run_id> --format markdownRun records are stored under ~/.mn/runs/<run_id>/ by default. Preserve events, logs, output artifacts, and timestamps when reporting a failure.
Cancel work
mn job cancel <job_id>
mn job status <job_id>Warning: cancellation stops runtime work but cannot reverse an external action already performed by a worker. Review a blueprint's output skills, adapters, and idempotency behavior before launching side-effecting workflows.
Diagnose a stuck or failed job
Collect read-only evidence first:
mn runtime health
mn runtime status
mn node list
mn job status <job_id>
mn job dead-letters <job_id>Use Troubleshooting for Redis, OpenShell, model, API, and cluster diagnosis. Include the job ID, run ID, timestamp, exact error text, and sanitized relevant configuration when escalating an issue.