> ## Documentation Index
> Fetch the complete documentation index at: https://chatobserver.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Runs

> How prompt executions are tracked, filtered, and interpreted.

# Runs

A run is a single execution of a prompt. Runs are where Chatobserver shifts from configuration to evidence.

## What a run tells you

Each run helps answer:

* did the prompt execute
* when did it start and finish
* what triggered it
* did downstream analysis complete
* is there an error to investigate

## Execution status

Current run status values include:

* queued
* running
* succeeded
* failed

These describe the execution lifecycle itself.

## Analysis status

Runs also carry a separate analysis state. A run may complete execution before downstream processing finishes, so treat execution success and analysis completeness as different checks.

Typical analysis states include:

* pending
* complete
* failed

## Trigger types

Runs can be created by:

* schedule
* manual action

Manual runs are useful for validating prompt changes or checking a specific question outside the normal cadence.

## How to review a run

When a run looks wrong, review it in order:

1. execution status
2. analysis status
3. prompt metadata
4. timing
5. related sources

That sequence makes it easier to separate a failed execution from a successful execution that simply has not finished post-processing.

## Common reasons to inspect runs

* validating a new prompt
* confirming schedule changes
* investigating why visibility metrics did not move
* checking whether source extraction is landing as expected
* isolating failures before they affect reporting

## When runs are healthy

You should see a steady pattern of completed runs across the prompt set you expect to be active. If the run log is sparse, stale, or filled with failures, solve that before drawing conclusions from visibility trends.