DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Runs, logs, and history

Read what a run did: its status, its step graph, its logs, its outputs, and how it compares to the runs before it.

TutorialNew userOperatorAutomation author

What you will do

  • A run finishes success, failure, warning, timed_out, or canceled. Pipeline runs explains what each status means operationally.
  • warning means work failed but was ignored: the failing task stays auditable as failure (ignored).
  • timed_out is what an expired run timeout or approval timeout produces — it is not a crash.
  • GET /v1/runs lists runs, GET /v1/runs/{runID} returns detail, and GET /v1/runs/{runID}/logs returns log records whose text is under line.
  • The run list filters on limit, offset, teamId, and branch. There is no pipeline filter: select on pipeline_name in the response.
  • POST /v1/runs/{runID}/rerun answers with runId, while POST /v1/run/{pipeline} answers with run_id — and only when the request carries Accept: application/json, otherwise it returns a plain-text confirmation.
  • POST /v1/runs/{runID}/rerun starts a new run from the same definition; POST /v1/runs/{runID}/cancel stops one in flight.
  • Declared secrets and outputs marked sensitive are masked wherever logs are rendered.

Before you start

A finished run
The run ID from the pipeline you built earlier
Token
A token allowed to read runs in that team and scope

Steps

  1. 01

    Find the run

    The run list is the entry point in the UI and over the API. Pipeline Runs shows the same records the API returns.

    List recent runsbash
    curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs" | jq '.[0:5]'
    Verify
    • Your run appears with its pipeline name and status.
  2. 02

    Read the run detail

    Run detail carries the execution graph and per-step state. In the UI, selecting a multi-task step reveals its task graph below the step overview.

    Fetch one runbash
    curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs/$RUN_ID" | jq
    Expected result
    • Steps in dependency order, each with its status and timing.
  3. 03

    Read the logs

    Logs are per run and stay attached to it. This is where the value your last step printed shows up.

    Tail the log linesbash
    curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs/$RUN_ID/logs" | jq -r '.[].line' | tail -30
    Verify
    • Secret values appear masked; non-sensitive outputs appear in clear text.
  4. 04

    Compare against history

    A single green run proves little. Pipeline detail keeps a Runs tab so you can see whether this run behaved like the ones before it, and Health carries the analysis surface.

    Filter the run list by pipelinebash
    curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs?limit=50" \
  | jq '[.[] | select(.pipeline_name == "first-pipeline") | {run_id, status, started_at}]'
    Verify
    • Both of your runs are listed, newest first.
  5. 05

    Re-run and cancel

    Re-running starts a fresh run from the same definition rather than resuming the old one. Cancelling stops a run that is still in flight.

    Rerun, then cancelbash
    RERUN=$(curl -sX POST -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs/$RUN_ID/rerun" | jq -r .runId)
curl -sX POST -H "Authorization: Bearer $NOPSAI_TOKEN" "http://localhost:8080/v1/runs/$RERUN/cancel" | jq
    Expected result
    • The rerun appears in history as its own record, and the cancelled run finishes as canceled.

How it works

Run list surfaces expose only an aggregate final_output_status. Generated deliverable content stays on authorized detail paths, so a list view never leaks output contents.

Pipeline detail is organised as Flow, Definition, Trigger rules, Runs, Health, and Dependencies. Health owns the full analysis result and the AI Evaluation surface.

System logs are a different thing from run logs: run logs are what your steps produced, system logs are the platform services. Reach for those when a run never started.

Implementation evidence

  • services/nopsai/routes.go

    Run list, detail, logs, rerun, and cancel routes.

  • doc/runtime-flows.md

    Cancellation, rerun, and child pipeline flows.