---
title: Deploy status and recovery
description: Inspect, watch, cancel, and recover a deployment.
---

Every deploy has an id (`d_…`). A verbose **service** deploy (`npx tori.host deploy --image … -v`) prints it. A static deploy does not; `npx tori.host deploy status` with no id is the latest attempt for the app in `./tori.json`. The console **deploys** tab lists the same ids.

```sh
npx tori.host deploy status
npx tori.host deploy status d_example
npx tori.host deploy watch d_example
```

See [tori deploy](/cli/deploy/) for flags. In the console, open the app → **deploys**.

## Status

`tori deploy status` (no id) is the latest attempt for the app in `./tori.json`. It prints the id, status, image (services), and the latest error or progress line.

Typical statuses:

| Status | Meaning |
| --- | --- |
| `building` | Accepted; not live yet (upload unpacking, or the service revision starting) |
| `live` | This attempt is what the URL serves |
| `failed` | Stopped. `error` is the reason |
| `cancelled` | A pending service attempt was cancelled; the previous live version remains |
| `superseded` | This attempt went live and a newer one has already replaced it |

`already live` on a service deploy means that image and environment are already the running revision; nothing new was started unless you passed `--restart`.

## Watching and interrupting

`tori deploy` and `tori deploy watch` wait until the attempt settles. **Ctrl+C stops watching; the deploy continues on the server.** The CLI prints the watch command (and `cancel` for a pending service).

If the CLI gives up after its wait (twenty minutes, matching the server), it says so. The deploy has **not** been cancelled. Check the URL, `deploy status`, or the console.

## Cancel

```sh
npx tori.host deploy cancel d_example
```

Cancellation applies only to **pending service** attempts. A queued source build, or an image deploy with no build, is cancelled immediately: the CLI exits 0 and another deploy can start. A leased or running source build is marked for cancellation and stays `building` until the builder acknowledges. The API answers 200 with that still-building row, so the CLI prints `The API did not confirm cancellation` and exits non-zero even though the request was accepted. Run `deploy status` or `deploy watch` until the attempt is `cancelled`; another deploy is refused with HTTP 409 until then. Resource cleanup follows in the zone. An existing live version remains available. A deploy that has already gone live cannot be cancelled. Repeating cancellation is harmless.

Static uploads that have already finished cannot be cancelled this way; wait for live or failed.

## Failures and recovery

The customer's copy of what went wrong is `deploys.error`. The CLI prints it as `deploy failed: …`. Common shapes:

| Reason | Recovery |
| --- | --- |
| Artefact too large, or a member file too large | Shrink the output; deploy again |
| Unsafe path in the archive | Stop packing `..` or absolute names |
| Image pull / `runAsNonRoot` / nothing listening on 8080 | Fix the image; deploy the new digest |
| Another deploy in progress | Watch or cancel that id; a running source build still occupies the slot until the builder acknowledges |
| HTTP 408 during upload | Retry on a faster link; nothing was stored |
| Plan cap (`app limit reached`, concurrent deploy cap) | Delete an app you do not need, wait for an in-flight deploy, or stay within the plan `whoami` shows |

Fix the cause, then deploy again: `npx tori.host` for a static site or a source-built service, or `npx tori.host deploy --image …` for a digest you brought. There is no “retry this id” command: a new deploy is a new id.

In the console, **deploys** can roll back a previous attempt whose artefacts are still present. A deploy whose files have been reclaimed cannot be rolled back; the API refuses and the console does not offer it. Rolling back a **service** deploy that had a release command runs that same command as a Job before traffic moves; if the Job fails, the rollback does not switch the revision.

## HTTP

```sh
curl -sS -H "Authorization: Bearer $TORI_TOKEN" \
  https://api.tori.host/api/apps/<slug>/deploys
```

```sh
curl -sS -H "Authorization: Bearer $TORI_TOKEN" \
  https://api.tori.host/api/apps/<slug>/deploys/<deployId>
```

```sh
curl -sS -X POST -H "Authorization: Bearer $TORI_TOKEN" \
  https://api.tori.host/api/apps/<slug>/deploys/<deployId>/cancel
```

Operation ids: `listDeploys`, `getDeploy`, `watchDeploy`, `cancelDeploy`, `rollbackApp` in the [API reference](/api/reference/).

Download this page as [Markdown](/downloads/markdown/guides/deploys.md).