Add an API endpoint for retrieving serverless container deployment logs

Feedback
1

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:

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.