# Add an API endpoint for retrieving serverless container deployment logs

**URL:** <https://forum.verda.com/t/add-an-api-endpoint-for-retrieving-serverless-container-deployment-logs/89>\
**Category:** Feedback\
**Created:** [September 7, 2026, 7:55am UTC](https://forum.verda.com/t/add-an-api-endpoint-for-retrieving-serverless-container-deployment-logs/89 "2026-09-07T07:55:26Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![erikd](https://avatars.discourse-cdn.com/v4/letter/e/b782af/32.png) [@erikd](https://forum.verda.com/u/erikd)\
**Post date:** [September 7, 2026, 7:55am UTC](https://forum.verda.com/t/add-an-api-endpoint-for-retrieving-serverless-container-deployment-logs/89/1 "2026-09-07T07:55:26Z")

</div>

## The Problem You’re Solving

Container logs for serverless deployments are currently only accessible through the Console UI. The public API has no logs endpoint — the OpenAPI spec under `/v1/container-deployments/{name}/` exposes status, replicas, scaling, environment-variables, pause/resume, restart and purge-queue, but nothing to read container logs (stdout/stderr).

As an operator running a production fleet of serverless inference deployments (SGLang and vLLM serving DeepSeek, Qwen and embedding models), we run into this limitation constantly:

- **Debugging cold-starts and replica issues** — when a replica fails to become healthy or a model takes 40 minutes to cold-start, the logs are the first place we look, and they can only be viewed manually in the console.
- **Correlating with metrics** — `/metrics` is available on the deployment gateway, so we can already scrape rich Prometheus metrics programmatically. Logs are the missing half of the observability picture; without them we can’t correlate error spikes in metrics with what the server actually printed.
- **Automation and alerting** — incident response, automated health monitoring and attaching logs to support tickets all require programmatic access. With Web-UI-only logs, every investigation is a manual, browser-based step.

For context: the metrics gateway (`containers.datacrunch.io/<name>/metrics`) already exists and is used by our benchmarking tooling — so logs are the one remaining gap for full API-based observability.

* * *

## Proposed Solution or Idea

Add a logs endpoint to the public API:

```auto
GET /v1/container-deployments/{deployment_name}/logs

```

with optional query parameters:

- `replica_id` — filter to a specific replica/pod
- `since` / `until` — time window (ISO 8601)
- `tail` / `limit` — number of most recent lines
- `format` — `text` (default) or `json` (structured, with timestamps and source)

Optional but highly valuable: an SSE streaming variant (`GET /v1/container-deployments/{name}/logs/stream`) for `tail -f`-style live debugging, mirroring how the gateway already handles SSE for inference responses.

A pragmatic MVP could be a pull-only endpoint with `since`/`tail` — that already unlocks most automation use cases.

* * *

## Benefits

- **Faster incident resolution** — logs become part of the standard API toolkit; debugging no longer depends on the browser.
- **Automation-ready operations** — log collection for alerting, scheduled health checks, and support-ticket attachments becomes scriptable.
- **Full observability parity** — pairs with the existing `/metrics` endpoint for a complete API-based monitoring story.
- **Brings Verda in line with major-cloud expectations** — AWS (CloudWatch Logs API), Azure (Monitor) and GCP (Cloud Logging) all expose logs API-first. This would close the most visible maturity gap for programmatic users.

* * *

## Possible Alternatives

- **Self-managed log shipping** — we currently work around this by shipping container stdout to our own log store via a sidecar in the deployment image. This works but adds per-deployment complexity and doesn’t cover events before the container starts (image pull, replica scheduling).
- **Console UI only** — fine for ad-hoc checks, but not scalable for a fleet of deployments.