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

# Statuses and events

> Look up every status a deployment or project can take, and every event kind.

## Deployment statuses

A deployment is one service's run at one commit, so these describe a single service. A push
that ships three services produces three deployments, each with its own status.

| Status | Meaning |
| - | - |
| `queued` | The deployment row exists and is about to start. |
| `building` | The service is being built. A service running a prebuilt image skips this. |
| `deploying` | The image is ready. The service is starting and slipway is waiting for readiness. |
| `healthy` | The service is ready and its public URL is live. |
| `failed` | A build, image pull, secret lookup, health check or dependency did not succeed. |
| `cancelled` | You cancelled it, or a newer commit for the same branch took over mid-build. |
| `superseded` | A newer healthy deployment of the same service on the same branch replaced it. |
| `sleeping` | Scaled to zero on idle. |
| `resuming` | Waking from sleep. |

`healthy`, `failed`, `cancelled` and `superseded` are terminal. Exactly one deployment per
service is live at a time.

## Deployment triggers

| Trigger | Cause |
| - | - |
| `push` | A push to the tracked branch |
| `pull_request` | A pull request opened or updated |
| `manual` | A deploy started from the console or the CLI |
| `rollback` | A rollback to a previous deployment |

## Project statuses

| Status | Meaning |
| - | - |
| `creating` | The row exists and nothing has deployed. |
| `ready` | Configured, with no deploy in flight. |
| `deploying` | One or more services are in flight. |
| `healthy` | Every service is healthy. |
| `degraded` | At least one service failed while others keep serving. |
| `failed` | Everything failed. |
| `sleeping` | Scaled to zero on idle. |
| `resuming` | Waking. |
| `tearing_down` | Teardown in progress. |
| `torn_down` | Torn down. The row stays for history. |

## Deployment events

Every deployment carries an append-only event log, rendered as the Timeline tab.

### Lifecycle

| Kind | Fires when |
| - | - |
| `queued` | The deployment was created. |
| `assigned` | It was assigned to a cluster. |
| `build_start`, `build_end` | A service's build started and finished. |
| `predeploy_start`, `predeploy_end` | A `preDeploy` job started and finished. |
| `deploy_start` | Workloads are being applied. |
| `service_ready` | One service passed its readiness check. |
| `cutover` | A public URL started serving this build. |
| `healthy` | Every service is ready. |
| `failed` | The deployment failed. The payload carries the reason. |
| `crashed` | The service went live and then started crash-looping. The payload carries the exit code, the restart count and the container's last output, which the log also quotes. The deployment's status stays `healthy`, because the deploy did succeed; the service's own status reads `failed` until a restart succeeds or a new deploy replaces it. |
| `unready` | The deploy finished, but the service's pods have run for five minutes without passing their readiness check, so nothing is routed to them. The payload names the probe (`readinessProbe`, such as `tcp 8080`), which is usually the port the app is not listening on. Same status rule as `crashed`: the service reads `failed` until the check passes. |
| `cancelled` | The deployment was cancelled. |
| `superseded` | A newer deployment replaced it. |
| `gc` | The deployment's resources were reclaimed. |

### Configuration resolution

| Kind | Fires when |
| - | - |
| `secrets_resolved` | Secrets were resolved. Carries `{name, scope, source}` per reference, never values. |
| `vars_resolved` | Variables were resolved. Carries values too, because variables are not secret. |
| `registries_resolved` | Private registry credentials were wired in, listing the hosts. |
| `service_refs_resolved` | `${service.*}` references resolved. |
| `service_refs_unresolved` | A `${service.*}` reference could not resolve. |
| `env_overrides_applied` | Preview or project-level environment overrides were applied. |
| `spec_settings_applied` | Spec-stamped settings such as `autoDeploy` or `previews` were applied. |
| `database_secret_provisioned` | A managed database's password was generated and stored. Names the secret, never the value. |

### Storage

| Kind | Fires when |
| - | - |
| `volumes_prepared` | Disks were created or attached. |
| `data_resolved` | The seed source for a disk was determined. |
| `data_cloned` | A disk was seeded from a snapshot. |
| `data_cloned_empty` | A disk started empty, because no snapshot was available. |
| `data_snapshot_taken` | A snapshot was captured. |

### Compute

| Kind | Fires when |
| - | - |
| `resources_clamped` | The requested allocation exceeded the plan cap and was trimmed. See [Plans](/plans). |
| `resources_resized` | An allocation changed on the running pods. Carries `{service, from, to, podCount}`. |

### Sleep

| Kind | Fires when |
| - | - |
| `sleeping` | A service scaled to zero on idle. |
| `resuming` | It started waking. |
| `awake` | It is serving again. |

### Warnings

| Kind | Fires when |
| - | - |
| `public_host_rejected` | Your application refused the request's `Host` header. Carries `{service, host, status}`, and the deploy stays healthy. See [Troubleshooting](/deploys/troubleshooting#the-deploy-is-green-but-the-url-returns-403). |
| `notification_failed` | Historical: a notification POST failed, back when delivery was fire-and-forget. Failures now live in the channel's [delivery history](/observability/webhooks#delivery-history-and-redelivery) instead. |

### Output

| Kind | Fires when |
| - | - |
| `log` | A line of build or container output. |

## Project events

| Kind | Fires when |
| - | - |
| `project_created` | The project was created. |
| `project_updated` | Its configuration changed. |
| `project_deploy_start` | A project-wide deploy started. |
| `project_redeploy` | A redeploy was requested. |
| `project_healthy` | Every service reached healthy. |
| `project_degraded` | Some services are healthy and some failed. |
| `project_failed` | The project deploy failed. |
| `project_cancelled` | The project deploy was cancelled. |
| `project_torn_down` | The project was torn down. |
| `project_clone` | The project was cloned, or created as a clone. |
| `service_deploy_start`, `service_deploy_end` | One service's deploy started and finished. |
| `service_healthy` | One service reached healthy. |
| `service_failed` | One service failed. |
| `service_name_conflict` | Two sources declared the same service name. |
| `project_sleeping`, `project_resuming`, `project_awake` | The project as a whole slept, woke or is serving. |
| `project_service_sleeping`, `project_service_awake` | A single service slept or woke. |
| `project_paused`, `project_resumed` | The workspace ran out of usage balance, was suspended, or had its subscription cancelled, and its projects were scaled to zero. The mirror event fires when they come back. `data.reason` says which. |
| `project_access_changed` | A security-relevant setting changed: access control on a service, inbound IP rules, an access token rotated or deleted, external database access, or a database credential created or deleted. Carries who made the change. |
| `service_renamed` | A service changed name and the deploy carrying the new name was accepted. `data.from` and `data.to` carry the names, `data.actor` who deployed it. Its id, history and settings carry across. |
| `service_crashed` | A service that had gone live started crash-looping. `data.service` names it; `data.exitCode`, `data.restarts`, `data.reason` and `data.lastOutput` say why. The service's Events feed shows it as "Crashed after going live", after the deploy that went live. |
| `service_unready` | A service's pods ran for five minutes after the deploy finished without passing their readiness check. `data.readinessProbe` names the check. Shown in the feed as "Never became ready". |

> [!NOTE]
>
> `project_degraded` counts as a failure rather than a success in the organization
> [metrics](/observability/metrics), because part of the project is down.

## Where events appear

| Surface | Shows |
| - | - |
| The deployment's **Timeline** tab | Every deployment event on a time axis |
| The deployment's **Logs** tab | `log` events, interleaved with slipway's narration |
| The project's **History** tab | Project events |
| [Notification channels](/observability/notifications) | `healthy`, `updated`, `failed` and `torn_down` |
| [The MCP server](/integrations/mcp) | Through `get_deployment` and `get_deployment_logs` |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.