Run History

Read the run list, understand statuses, and investigate failures.

Overview

Every time a bot runs, whether you triggered it by hand or a schedule did, BotHound records it in the run history. The run history is the single place you go to see what the bot did, how long it took, and what it cost.

The run list

The run list shows every run for a bot. Each row includes:

  • Status. Where the run is in its lifecycle.
  • Trigger source. Manual or scheduled.
  • Started at. When the run began.
  • Duration. How long it took from start to finish.
  • Credits charged. What the run cost you.

Click any row to open the run detail.

Statuses

  • Queued. The run has been created and is waiting for a worker to pick it up.
  • Running. A worker is actively executing the plan. Tasks are producing output.
  • Completed. The run finished all stages without error. The output is available.
  • Failed. The run hit an error it could not recover from. Credits are refunded automatically.

Credits and refunds

Each run is charged upfront when it starts. If the run fails, the charge is refunded automatically. If the run completes, the charge stands. You can see the credit movement on every run’s detail view.

Investigating a failed run

Open the run and look for:

  1. Per-task output. Which task was the last one to complete successfully? The failure is almost always at the next stage.
  2. Error messages. Failed tasks include an error message. Common causes: a tool could not reach an upstream service, a prompt produced output the next task could not parse, or input data was missing.
  3. Tokens used. A run that stopped very early usually points to a soul or prompt issue. A run that ran long before failing usually points to a tool or upstream issue.

Once you know which stage failed, go back to the bot’s tasks and iterate on that task. Run manually a few times until it succeeds, then let the schedule pick up again.

When schedules fail

A failing run does not pause the schedule. If the same run is failing repeatedly, pause the schedule while you investigate so you are not burning through retries. Flip it back to active when you are confident the fix is in. See Schedules.