HTTP API¶
Overview¶
Watchtower has an optional HTTP API server.
Caution
This is a relatively simple API with significant security implications.
Endpoints¶
| Name | Method | Endpoint | Parameters | Description |
|---|---|---|---|---|
| Update | POST |
/v1/update |
image |
Triggers container updates and returns JSON results of the operation |
| Metrics | GET |
/v1/metrics |
Exposes Prometheus-compatible metrics for monitoring and alerting |
Note
Endpoints enforce HTTP method restrictions using method-based routing.
Requests with unsupported methods will receive a 405 Method Not Allowed response.
HTTP API Update¶
To enable this mode, use the --http-api-update CLI argument or the WATCHTOWER_HTTP_API_UPDATE environment variable.
Response Format¶
The /v1/update endpoint returns a JSON response containing the results of the update operation:
{
"summary": {
"scanned": 8,
"updated": 0,
"failed": 0,
"restarted": 0,
"skipped": 2
},
"timing": {
"duration_ms": 1250,
"duration": "1.25s"
},
"timestamp": "2025-01-20T11:30:45Z",
"api_version": "v1"
}
Summary Section¶
scanned: Number of containers that were scanned for updatesupdated: Number of containers that were successfully updatedfailed: Number of containers where the update failedrestarted: Number of containers that were restarted due to linked dependenciesskipped: Number of containers that were skipped during the update
Timing Section¶
duration_ms: Execution time in millisecondsduration: Human-readable execution time
Metadata¶
timestamp: UTC timestamp when the response was generated (RFC3339 format)api_version: API version identifier
HTTP Status Codes¶
The /v1/update endpoint returns the following HTTP status codes:
| Status Code | Description |
|---|---|
| 200 | Update completed successfully |
| 401 | Invalid or missing authentication token |
| 429 | Another update is already in progress (full updates only) or the request was rate limited |
| 500 | Internal server error during request processing |
Error Response Format¶
When an error occurs, the API returns a JSON response with the following structure:
{
"error": "another update is already running",
"api_version": "v1",
"timestamp": "2025-01-20T11:30:45Z"
}
error: A human-readable error message describing what went wrongapi_version: API version identifiertimestamp: UTC timestamp when the error response was generated (RFC3339 format)
Concurrency Behavior¶
The /v1/update endpoint handles concurrent requests differently based on whether targeted or full updates are being performed:
Full Updates (no ?image= parameter):
- Returns HTTP 429 immediately if another update is already in progress
- Includes a
Retry-After: 30header suggesting when to retry the request - Does not block or wait for the existing update to complete
Targeted Updates (with ?image= parameter):
- Blocks until the update lock is available
- Waits for any in-progress update to complete before proceeding
- Does not return HTTP 429
This behavior ensures that full updates (which may be resource-intensive) are not queued up, while targeted updates (which are typically faster) can wait for their turn.
Example 429 Response¶
The following example shows what happens when a full update is requested while another update is already running:
Response:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
{
"error": "another update is already running",
"api_version": "v1",
"timestamp": "2025-01-20T11:30:45Z"
}
The client should wait at least 30 seconds (as indicated by the Retry-After header) before attempting another request.
Security¶
Authentication¶
Watchtower uses token-based, header authentication for the HTTP API.
- This should be set using the HTTP API Token configuration option.
- All HTTP API endpoints (
/v1/updateand/v1/metrics) require anAuthorization: Bearer <token>header with the predefined HTTP API token value. - Invalid token attempts for any endpoint requiring auth (
/v1/updateand/v1/metrics) are logged with the token length (not the token value)
Rate Limiting¶
Watchtower enforces two independent mechanisms that can each return HTTP 429 (Too Many Requests):
Per-IP request-rate limiting (applies globally to all HTTP API endpoints):
- Every incoming request to any HTTP API endpoint (
/v1/update,/v1/metrics, etc.) is checked against a per-IP rate limiter before authentication is evaluated. - Default limit: 60 requests per minute with a burst capacity of 10 requests.
- Configurable via
--http-api-rate-limitflag orWATCHTOWER_HTTP_API_RATE_LIMITenvironment variable. - Rate-limited requests receive HTTP 429 with no body.
- Rate limit state is tracked per client IP address.
Concurrency-based update limiting (applies only to /v1/update):
- The
/v1/updatehandler uses an internal lock to ensure only one update runs at a time. - If a full update (no
imagequery parameter) is requested while another update is already in progress, the handler immediately returns HTTP 429 with a JSON error body and aRetry-After: 30header. - Targeted updates (with
imagequery parameter) block until the lock is available rather than returning 429.
Precedence: Per-IP rate limiting is evaluated first. If a request passes the rate limit, it proceeds to the endpoint handler where concurrency limiting may apply for /v1/update.
Request Body Protection¶
- Request bodies are capped at 1 MiB to prevent resource exhaustion from large uploads
- Requests exceeding this limit will be rejected with HTTP 413 (Payload Too Large)
Address and Port Configuration¶
Watchtower defaults to listening on all interfaces on port 8080.
HTTP API Host¶
Use the HTTP API Host configuration option to bind to a specific host interface.
- This must be a valid IP address (IPv4 or IPv6).
- If not specified, Watchtower listens on all interfaces on the port specified by
--http-api-port.
HTTP API Port¶
The port can be changed using the HTTP API Port configuration option.
If Watchtower is being run via a Docker container, then the host:container port mapping can be updated accordingly (e.g. 8080:8080 -> 9000:8080).
Examples¶
- Listen on all interfaces on port 8080 (default):
- Listen on localhost only on port 8080:
- Listen on a specific IP and port:
Image Parameter Usage¶
Watchtower supports using the image URL query parameter to filter updates for only certain images.
No Image Filtering¶
The following curl command would trigger an update of all container images monitored by Watchtower:
Image Filtering with Tags¶
You can specify image tags to target containers running a specific version (e.g., foo/bar:1.0).
For example, to update only containers using foo/bar:1.0 and foo/baz:latest:
curl -X POST -H "Authorization: Bearer mytoken" localhost:8080/v1/update?image=foo/bar:1.0,foo/baz:latest
Image Filtering without Tags¶
If no tag is provided, Watchtower matches containers regardless of their tag.
The following curl command would trigger an update for the images foo/bar and foo/baz:
Using the HTTP API and Periodic Updates¶
By default, enabling the HTTP API prevents periodic updates (i.e. scheduled or interval polling).
Use the HTTP API Periodic Polls configuration option to enable periodic updates while using the HTTP API.
Example¶
services:
app-monitored-by-watchtower:
image: myapps/monitored-by-watchtower
labels:
- "com.centurylinklabs.watchtower.enable=true"
watchtower:
image: nickfedor/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: --http-api-update --http-api-metrics
environment:
- WATCHTOWER_HTTP_API_TOKEN=mytoken
labels:
- "com.centurylinklabs.watchtower.enable=false"
ports:
- 8080:8080
restart: unless-stopped
Note
Both --http-api-update and --http-api-metrics can be enabled simultaneously to provide both update triggering and monitoring capabilities.
Warning
Enabling the HTTP API with port mappings will automatically disable Watchtower's self-update functionality to prevent port conflicts during container recreation. See Updating Watchtower for more details.