Logs

Logs provide detailed messages from functions, application code, and selected platform components, correlated to individual requests.

Where logs appear

• Logs in the project dashboard: request list, detail panel, and dock
• easel logs in the terminal

Build output lives with the deployment (inspect build logs from Deployments or the CLI). Request Logs focus on runtime traffic after a deployment is serving requests.

Request list and filters

Logs lists recent requests for the project. Filter by:

• Time range
• Environment
• Method
• Status
• Path and route
• Host
• Cache status
• Console level (warning, error, fatal)
• Deployment ID

Select a row to open detail. The dock Logs tab shows function and platform log lines for that request.

Application logs

Write to standard console APIs in your function runtime. Easel captures console output and associates it with the request ID when available.

Prefer structured JSON when you need searchable fields:

{
  "level": "info",
  "message": "Checkout completed",
  "order_id": "ord_123"
}

Do not log secrets, tokens, or full connection strings. Automatic redaction cannot catch every transformed value. See Secrets.

Correlation fields

Useful identifiers:

From an Invocation, use Open in Logs or filter with invocationId:….

CLI

easel logs
easel logs --follow --expand --timeout 10m
easel logs --environment production --status-code 5xx --since 1h
easel logs --request-id <request-id>

--follow polls for new requests. --expand prints function log lines for each request.

See Query request logs for the full option list.

Capture limits

Function log capture is bounded per invoke so telemetry cannot keep the runtime open indefinitely. Very chatty processes may drop excess lines. Prefer concise, structured messages for high-volume paths.

Delivery is best-effort and must not block the request path. Do not treat Logs as a guaranteed audit archive.

Related guides

• Request details
• Tracing
• Function observability
• Query request logs (CLI)