# Follow a run

Watch an execution from dispatch to result, and work out where a failed one broke.

The runs list on the Monitor page shows the development environment's runs, whether they were scheduled or triggered by hand. Runs in test, acceptance, and production do not appear there yet. Each row carries when it ran, which source and job it belonged to, which schedule dispatched it (if any), its status, how long it took, and how much data it moved.

![A failed run in Monitor with its status, duration, rows, size and error counts above the objects table, where sales.orders has failed. Below it, the Checkpoints list shows extract succeeded and load failed, both collapsed.](demos/guides/monitoring-follow-a-run-light.png)
{mode="true" class="guide-image"}

## What the statuses mean

| Status | Meaning |
| --- | --- |
| Running | The agent has started it, and it has not finished |
| Success | Finished without an error |
| Failed | Ended with an error, or went silent and the platform marked it failed |
| Cancelled | Canceled before it started moving data. A run canceled while it is moving data shows as Failed |

Beside the status, a row can carry an error chip and a warning chip, each with its count. A warning is not a failure, but it is not nothing either. A Success with a warning chip is the row most worth opening, because the run completed while telling you something.

## Reading a failed run

Work through it in this order, which goes from cheapest to check to most expensive:

1. **Is the agent connected?** The platform records a run only once its agent starts it, so a run whose agent is down never appears in the list. If you triggered a run and no row shows up, check the agent first. See [Check agent health](/docs/guides/cli/check-agent-health/).
2. **What does the run itself say?** Open it, expand the failed step under **Checkpoints**, and read the error it reported. If that is not specific enough, read the agent's own log (see below).
3. **Are the credentials still good?** Rotated source or platform credentials fail at connect time, and they fail for every run at once rather than for one object.
4. **Did the source change?** A run that used to work and now does not, on a source nobody touched in Amfelt, is often schema drift. See [Review schema drift](/docs/guides/catalog/review-schema-drift/).

## The agent's own log

The agent's log stays on the host it runs on, and the platform keeps no copy of it. It is where to look for detail the run page does not give. The agent writes it to standard error, so you will find it wherever that host keeps a service's output: the systemd journal, for example, or your container runtime's logs.

## Next

[Read metrics and run history](/docs/guides/monitoring/logs-and-metrics/) for the pattern across runs rather than the detail of one.