# Exit codes | DRE

> What each dre exit code means, so a scheduler knows whether to retry, alert or stop.

You're reading the docs for DRE 0.4 (v0.4.4). [This page for 0.5](https://getdre.com/docs/exit-codes/) · [New in 0.5](https://getdre.com/docs/new-in-0.5/)

# Exit codes

Orchestrators decide from a command’s exit code whether to retry a job, alert someone or stop. Every `dre` command uses the same codes:

Code

Meaning

What to do

`0`

Everything succeeded. Skipped outputs (`when:` false, a `{deliver: false}` destination) count as success.

Nothing.

`1`

The command ran, but something failed: a report or a delivery (details per Binding in [`run_results.json`](https://getdre.com/docs/v0.4/manifest/)), or problems `dre validate` found.

Look at the failures. A retry may help when the cause was temporary (a connection, the warehouse).

`2`

The command couldn’t start: bad flags or environment, an invalid project or profile, an unknown selection, a missing plugin. Nothing ran.

Fix the cause; retrying won’t help.

`124`

The run took longer than its timeout (`--timeout`, `DRE_RUN_TIMEOUT`, `flags: run_timeout`); the running Binding is recorded as `timed_out`.

Raise the timeout, or look at what was running.

`130`

Cancelled by Ctrl-C (SIGINT); the running Binding is recorded as `cancelled`.

`143`

Cancelled by a termination signal (SIGTERM; on Windows Ctrl-Break, closing the console, logging off or shutting down), as an orchestrator sends when it cancels a job.

There’s no separate code for a run where some reports failed and others delivered: `1` means something failed, and each Binding’s `run_results.json` says which.

For `dre validate`, `dre compile`, `dre deps` and `dre ls`, `1` means the command ran and found problems and `2` means it couldn’t run (no project, bad flags). Warnings exit `0`; `dre validate --strict` treats them as errors, so they exit `1`.

Each problem DRE reports also has an [error code](https://getdre.com/docs/v0.4/reference-error-codes/), whose kind says the same in more detail: a usage, config, plugin or refusal problem stops a command from starting (`2`), and a connection, authentication, query or delivery problem during a run makes it fail (`1`).

Before 0.4, `dre run` exited `1` for an invalid project as well as for a failed report; it now exits `2` for the first.

## Preserve the process status in a job

The complete [orchestration recipe](https://getdre.com/docs/v0.4/orchestration/) records the process status rather than guessing from a message. For a minimal shell wrapper around the [tutorial project](https://github.com/get-dre/dre/blob/v0.4.4/examples/tutorial/):

```bash
cd examples/tutorial || exit 2
dre run --preview 5
status=$?
case "$status" in
  0) echo "Report completed" ;;
  1) echo "Inspect the run's result before deciding to retry" ;;
  2) echo "Fix configuration before retrying" ;;
  124|130|143) echo "Run stopped; inspect its recorded status" ;;
esac
exit "$status"
```

Capture `$?` immediately; another command overwrites it. A pipeline into `tee` can report `tee`’s success instead of DRE’s failure unless the shell uses `pipefail`. An exit code of `1` does not prove retrying is safe: some destinations may already have received files. Use [error codes](https://getdre.com/docs/v0.4/reference-error-codes/) and per-[Binding](https://getdre.com/docs/v0.4/glossary/#binding) [run results](https://getdre.com/docs/v0.4/glossary/#run_resultsjson) to inspect the failed step.

[Previous  
Tested examples](https://getdre.com/docs/v0.4/examples/)[Next  
Your first report in 10 minutes](https://getdre.com/docs/v0.4/first-report/)