# health-check Specification

## Purpose
Expose a public `GET /up` healthcheck that responds quickly and without authentication, exposes no secrets, and fails when the application cannot boot, so orchestrators and CI can verify availability.
## Requirements
### Requirement: Public health endpoint responds without authentication

The system SHALL expose `GET /up` as a public healthcheck endpoint that does not require authentication.

#### Scenario: Application is healthy

- **WHEN** a client sends `GET /up` while the application is running normally
- **THEN** the system responds with HTTP 200 in a timely manner

#### Scenario: Health endpoint exposes no secrets

- **WHEN** a client sends `GET /up`
- **THEN** the response MUST NOT include credentials, tokens, stack traces, or environment secrets

### Requirement: Health endpoint reflects application failure

The system SHALL return a failure status when the application cannot initialize properly.

#### Scenario: Application cannot boot

- **WHEN** the application fails to boot due to misconfiguration or missing dependencies
- **THEN** the health endpoint MUST NOT return HTTP 200

### Requirement: Staging health and smoke use the public /up endpoint

Staging healthchecks and post-deploy smoke MUST call `GET /up` without authentication and MUST treat a non-200 response as deployment failure (SPEC §15.5, §16.2). The health response MUST NOT expose secrets.

#### Scenario: Staging healthcheck probes /up

- **WHEN** Dokploy or the container runtime evaluates application health after deploy
- **THEN** it MUST request `/up`
- **AND** MUST require HTTP 200 before marking the service healthy

#### Scenario: Smoke failure on /up fails the deploy gate

- **WHEN** post-deploy smoke requests `/up` and receives a non-200 response
- **THEN** the staging promotion MUST be considered failed