# `jadpo why`

Explain why a schedule didn't run.

Answers why a schedule didn't run, or how its last run went (area 17), from its state and run records: it is paused, a run still holds its lease, a lost run held its lease past its expiry, ticks stopped arriving, or its last run failed, with the failure's code and kind. The answer comes first, then its facts, then the .jadpo place the schedule is declared in. Requests, events and records come with debugging (area 17).

```text
jadpo why <name>
```

## Arguments

- `name`: The schedule's name

## Flags

- `--url <url>`: The database the schedules' state is in

## On every command

- `--json`: Print data for tools instead of text
- `--help`: Show every flag, with examples
- `--color <when>`: Choose when to use colour

`jadpo why --json` writes one JSON document to standard output instead of text, with the same exit code. The document has `schemaVersion`, `command` (`"why"`), `ok`, `data` (what the command produced, `null` when it failed) and `diagnostics` (each error with its `rule`, `reason`, `next` and `help`). A command that needs a terminal refuses `--json` and names the flags that do the same job.

## Examples

```text
# Find out why a schedule hasn't run
jadpo why nightly_digest
```

## Errors

- [`cli.why_arguments`](../errors/cli.why_arguments.md): Why command has invalid arguments
- [`schedules.unavailable`](../errors/schedules.unavailable.md): Schedules' database couldn't be read
- [`toolchain.project_not_found`](../errors/toolchain.project_not_found.md): Project could not be found