Logs

One stream, not four dashboards. Your app's request lines and stdout, platform and deploy events, cron runs and grouped errors all land on the same timeline. Open Logs in the console, or tail from the terminal:

camplax logs                    # recent entries
camplax logs --tail             # live stream until Ctrl+C
camplax logs --filter errors    # only error-level lines and 5xxs
camplax logs --search "timeout" # filter expression

Runtime logs — nothing to configure

Your app does not need a logging client. The Camplax runtime wrapper around your process captures two things on its own:

• Every HTTP request — method, path, status and duration, with a requestId per request.
• Everything your code writes to stdout and stderr — console.log, stack traces, framework output.

The platform injects CAMPLAX_LOG_INGEST (the ingest URL) and CAMPLAX_LOG_INGEST_TOKEN (the bearer) into the Machine's environment and the wrapper ships batched entries to POST /v1/logs/ingest. Both are stripped before your code starts — they belong to the platform, so a dump of your app's env is not a credential leak. Writing to standard out is the whole integration.

The ingest endpoint itself accepts a platform bearer token and a JSON body:

{
  "projectSlug": "my-app",
  "entries": [
    {
      "level": "info",
      "kind": "order.created",
      "message": "Order 1847 created",
      "method": "POST",
      "path": "/api/orders",
      "status": 201,
      "durationMs": 42,
      "requestId": "req_9f2…"
    }
  ]
}

• Up to 100 entries per call. message is capped at 16 KB, stack at 32 KB.
• Fields an entry can carry: id, at or timestamp, level (debug, info, warn, error), source, kind, environment (production or preview), method, path, status, durationMs, requestId, traceId, stack.
• A status of 500 or higher is stored as error-level regardless of the stated level.
• Error-level entries are fingerprinted into error issues on the way in, so a crashing route shows up in the inbox too.

Deploy logs

Build output lives with the deploy it came from — open a deploy in the console to read the full builder log. Every deploy log also has a shareable link:

GET /v1/deploy-logs/<slug>/<deployId>?token=<token>

The link returns plain text with no sign-in — it is the same URL that goes into deploy-failure emails, so you can paste it into a chat or an issue. Treat the link itself as a secret: anyone holding it can read that build's output.

Reading the stream

Search has two modes: the default filter expression (field matches and free text) and regex mode for patterns. Regex runs in a bounded engine — it reports a regexLimitation note rather than backtracking forever.

Request ids

Every request line carries a requestId, and entries you emit can carry one too — put it in the entry and the same id correlates your own lines with the request that produced them. Searching a request id returns every line for that request.

The dedicated trace view is not wired yet: GET /v1/projects/:slug/logs/traces/:requestId currently answers traces_not_enabled. Request-id search is the way to follow one request today.

Retention and limits

• The live tail keeps the last 2,000 entries or 7 days, whichever ends first. It is a rolling buffer for debugging, not an archive.
• Error groups, activity events and cron history are durable records — they outlive the tail.
• Export is possible at the platform level: the control plane can mirror entries to an OTLP/HTTP collector when one is configured for the deployment.

The same stream, three ways

• Console — the Logs page merges all sources with chips, search and the live tail.
• CLI — camplax logs [--tail] [--filter errors] [--search <q>]; see the CLI reference.
• API — the endpoints above accept a session, a cx_cli_ token, or a project key with the logs:read scope — see API keys.