Error Logging

Every sandbox has debug logging enabled by default. Since sandboxes are development environments, there's no reason to keep errors hidden.

How it works

When a sandbox is active, Rudel sets WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false. WordPress writes PHP errors, warnings, and notices to debug.log inside the sandbox's own wp-content directory. Errors never appear in the browser output, and each sandbox's log is completely separate from the host and from other sandboxes.

The log file is created automatically the first time WordPress encounters an error. You don't need to configure anything.

Viewing logs

wp rudel logs my-sandbox-a1b2

This shows the last 50 lines of the sandbox's error log. To see more:

wp rudel logs my-sandbox-a1b2 --lines=200

To watch the log in real time as errors come in:

wp rudel logs my-sandbox-a1b2 --follow

This works like tail -f. Press Ctrl+C to stop.

Clearing logs

wp rudel logs my-sandbox-a1b2 --clear

This empties the log file without deleting it. Useful when you want a clean slate before testing something specific.

Log location

The log file lives at {sandbox}/wp-content/debug.log. If you prefer to work with it directly, you can cat, grep, or open it in any editor. The wp rudel logs command is just a convenience wrapper.

Since sandboxes set WP_DEBUG_DISPLAY to false, errors won't break the frontend output even when debug mode is on. This makes it safe to leave logging enabled permanently, which is the intended behavior for disposable environments.

Blocked emails

Sandboxes block outbound email by default. When an email would have been sent, it's logged to the sandbox's debug.log instead, with the recipient and subject line:

Rudel: email blocked in sandbox my-sandbox-a1b2 (to: user@example.com, subject: Password Reset)

This means wp rudel logs shows both PHP errors and blocked email attempts in one place.