Logs

Every environment ships its logs into the dashboard automatically. There are two streams — application logs (your PHP errors, warnings, and notices, plus anything WordPress or your plugins write) and access logs (one line per HTTP request from the FrankenPHP runtime). You read both in one place, scoped to the environment you’re looking at, with no SSH required for the common case.

Live tail

The logs view streams in real time over server-sent events (SSE), so new lines appear as they happen — no refresh, no polling. Leave it open while you reproduce a bug and watch the error land.

The Insights → Logs view for a preview environment, live-tailing application logs with a severity filter set to Error and above, each line showing timestamp, severity badge, and message, newest at the bottom.

Filtering

Two filters do most of the work:

• Severity — narrow to error and above when you’re chasing a failure, or drop to debug when you need everything. Levels follow the usual ladder: debug, info, notice, warning, error, critical.
• Time — pin to a window (the last 15 minutes, the last hour, or a custom range) to line a log up with a deploy or a traffic spike.

Severity comes from the log body

managed.dev reads severity from the structured log record itself, not from a guess based on the text. A plugin that logs a stack trace at info will show as info — filter on the level your code actually emits.

Finding an error fast

A reliable path from “something’s broken” to the line that explains it:

1. Open the affected environment and go to Insights → Logs.
2. Set severity to Error and above to cut the noise.
3. Set the time window to bracket when the problem started — right after a deploy is the usual suspect.
4. Reproduce the request if you can; with the live tail running, the error appears as it happens.
5. Got a request that’s slow rather than failing? Jump to Traces to see where the time went, or to Requests for the status-code and latency view of that path.

Reading logs over the API

The same logs are available under the observability:read scope, which is handy for shipping them into your own aggregation or alerting. The collection paginates with a cursor like everything else in the API.

cURL

Tail recent error logs

curl https://api.managed.dev/v1/environments/env_01J8.../logs?severity=error&limit=50 \
  -H "Authorization: Bearer mfk_live_..."

mf CLI

Tail recent error logs

mf logs --env env_01J8... --severity error --limit 50

See the observability API resource for the full parameter list and the streaming endpoint.

Retention

Logs are retained for a rolling window so recent history is always there when you need to reconstruct an incident. Retention windows per plan are being finalized; for anything you need to keep long-term, ship logs out via the API to your own store.

Note

Need the raw files or a one-off grep across a large window? You can always reach an environment over the SSH gateway and read logs on the host directly.

Next steps

TracesFrom a logged error to the full request timing across the stack.

RequestsStatus codes, latency, and paths for every request.

Observability APIQuery logs, metrics, and traces under observability:read.