Logs

# About logs

Every environment collects logs from the PHP runtime, the web server, and background jobs. They are the first place to look when a request fails, a page turns white or traffic behaves unexpectedly.

# Accessing logs

Logs are available in the dashboard under the environment's Logs tab. There is no need to log in via SSH to read them.

# Log sources

The dashboard groups logs into four sources, selected with the source switcher. They line up with the layers a request travels through:

browser  →  Apache (web server)  →  PHP runtime (app)
            ───────────────────     ─────────────────
            access + error logs     PHP log

Apache is the front door. It accepts every HTTP request, applies rewrites and access rules, then hands the request to the PHP runtime that runs the app. The access log records each request Apache serves and the status it returned; the Apache error log holds problems in that web-server layer, before or around the hand-off. The PHP log holds whatever the application itself emits once the request reaches it. Background work runs outside this path and writes to the Jobs log.

That split is what makes the sources complementary: a failed page shows up as a status code in the access log, while the reason lives one layer down — in the PHP log for an application crash, or in the Apache error log for a rewrite or permission problem that never reached the app.

Only application output written to stderr and stdout reaches the PHP and Jobs logs — see Log files in the CMS or framework if either stays empty.

# PHP logs

Application errors from the PHP runtime: uncaught exceptions, fatal errors, warnings, and notices, plus anything the code sends through error_log() or a framework logger such as Monolog. Each line is tagged with a severity — from NOTICE and WARNING up to ERROR — so filtering to ERROR cuts a noisy log down to what actually broke.

[04-Jul-2026 08:15:42 UTC] PHP Warning:  Undefined array key "email" in /srv/app/htdocs/src/Newsletter.php on line 42
[04-Jul-2026 08:15:43 UTC] PHP Fatal error:  Uncaught RuntimeException: Database connection refused in /srv/app/htdocs/src/Db.php:31

This is the first place to look when a page turns white or returns a 500: the fatal error and its stack trace are usually the last ERROR line before the failed request. Lower levels such as notices and deprecations only appear when the application's own error_reporting includes them — a strict production config may suppress them entirely.

# Access logs

One line per HTTP request, in the Apache combined log format — client IP, timestamp, request method and path, response status code, response size, referrer, and user agent:

203.0.113.7 - - [04/Jul/2026:08:15:42 +0000] "GET /pricing HTTP/1.1" 200 5312 "https://example.com/" "Mozilla/5.0 …"

Every request Apache serves is recorded here, whether it succeeded or was rejected before the app ran, which makes the access log the place to see how the server answered each one. Filter by method, status, or IP address to watch a rollout, find the URLs returning 404, or trace a burst of error responses back to a single client. Clicking a status code or IP address in a line filters to it directly.

• 500 Internal Server Error
• 503 Service Unavailable
• 504 Gateway Timeout

# Apache error logs

The web server's own error log, separate from the application. It captures the problems Apache hits around a request: .htaccess rewrite mistakes, file and directory permission errors, denied access, and requests it could not route or fulfill. When a URL misbehaves but the PHP log stays quiet, the cause is usually here.

Each line carries a syslog severity (notice, warn, error, crit …) and, where Apache attributes one, a short AHxxxxx code — for example AH01630 for a request denied by server configuration. Those codes are stable identifiers, so they are worth searching or filtering for.

[Sat Jul 04 08:15:42.123456 2026] [authz_core:error] [pid 12345] [client 203.0.113.7:52134] AH01630: client denied by server configuration: /srv/app/htdocs/.env

• Apache error codes

# Jobs logs

Everything printed by the Jobs component — long-running workers and scheduled, cron-style commands — captured from their stdout and stderr. The source only appears once the Jobs component is booked. Use it to confirm a scheduled task ran at its due time and to read the output or error a job left behind. Application errors thrown inside a job still land in the PHP log; this source is the job runner's own output.

[2026-07-04T08:15:42+00:00] worker.INFO: Processing App\Jobs\SendInvoiceEmail {"id":"9f3c"}
[2026-07-04T08:15:43+00:00] worker.ERROR: SMTP connect failed, retrying in 60s

# Browsing and filtering

The log view streams lines newest first and can be narrowed down without leaving the page:

• Filter by level — limit PHP, Apache error, and Jobs logs to a severity such as ERROR or WARNING.
• Filter by method and status — for access logs, narrow down to a request method (GET, POST, …) or an HTTP status code (404, 500, …).
• Filter by IP — click an IP address in an access or Apache error line to filter for it, or look it up on ipinfo.io.
• Search — free-text search across the visible lines.
• Pick a time range — jump to a preset like today or yesterday, or define a custom day and hour. Times are UTC.
• Follow live — keep the latest lines streaming in as new requests come in.
• Load more — page further back through the history.

Clicking a level, method, or status code in a line filters for that value, so drilling into one kind of event takes a single click.

# Downloading logs

To keep logs or analyze them elsewhere, switch to Download, pick a source and a time range, and request a download link. The export is queued and a link is mailed once it is ready. Larger ranges take a few minutes to prepare.

# Tailing logs over SSH

The browser log view above is the recommended way to read logs. Live streaming is also available in the terminal:

1. Log in to the environment by SSH
2. Run frbit-tail-logs

This tails stderr and stdout as a live stream.

# Log files in the CMS or framework

A CMS or framework might pipe logs to a different location, other than stderr and stdout. In that case the output does not show up in the dashboard. The logs can still be read by SSH or SFTP — see the CMS / framework docs for where they are stored.

Most CMS and frameworks also offer options to send logs to the standard locations. With the software template the setting is pre-populated by ENV var where possible.

• Craft CMS logging
• Laravel logging

# Verbose logging

A CMS / framework might offer verbose logging, often tied to its environment settings. This prints more debugging information with each error, and sometimes sends errors to the browser. Use it with care, as it can have a considerable performance impact. The general advice is to use verbose logging on development and staging environments, but not in production. If an issue in production requires it, turn it off again once finished.