How to read wp-content/debug.log without SSH

When something misbehaves in WordPress, the first thing an experienced dev reaches for is the log. debug.log is where WordPress records the errors, warnings, and deprecations that never make it to the screen. The trouble isn’t turning it on — that’s two lines — it’s reading it on a live site without shelling in.

Turn logging on

In wp-config.php, above the /* That's all, stop editing! */ line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // write to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // don't print errors on the front end

From now on WordPress appends errors to wp-content/debug.log. WP_DEBUG_DISPLAY set to false is important on production — you want the errors in the file, not on the page in front of visitors.

You can also send the log somewhere other than the default by passing a path to WP_DEBUG_LOG (a string instead of true), but the default location is fine for most sites.

The hard part: reading it

Now the log is filling up — and to read it you need to get at a file inside wp-content. Your options, roughly in order of pain:

FTP / SFTP

Connect with an FTP client, navigate to wp-content, download debug.log, open it. Works everywhere, but it’s a lot of clicks for “what just errored,” and the file keeps changing so you’re re-downloading constantly.

Your host’s file manager

Most hosting panels (cPanel, Plesk, managed dashboards) have a file manager where you can open debug.log in the browser. Better than FTP, but it’s buried a few menus deep and it doesn’t update live.

SSH (if you have it)

If your host gives you shell access:

tail -f wp-content/debug.log

tail -f streams new lines as they’re written — great for reproducing a bug and watching it land. But plenty of shared and managed hosts don’t offer SSH at all, and even when they do, it’s not something you hand a junior or a client.

A log-viewer plugin

The no-shell answer is to read the log from inside wp-admin. A viewer plugin tails debug.log (and the PHP error_log) for you, in the dashboard, with no FTP, no file manager, and no SSH.

Why the raw file is painful anyway

Even once you’ve got debug.log open, it’s a wall of text:

[12-Aug-2026 09:14:02 UTC] PHP Warning:  Undefined array key "id" in /wp-content/themes/acme/functions.php on line 88
[12-Aug-2026 09:14:02 UTC] PHP Deprecated:  strlen(): Passing null to parameter #1 ($string) in /wp-content/themes/acme/functions.php on line 120
[12-Aug-2026 09:14:03 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function acme_init() in /wp-content/plugins/acme/acme.php:42

One repeating warning can print thousands of times and bury the one fatal you actually care about. There’s no grouping, no counts, no search — just chronological noise.

A faster workflow

This is exactly the friction FatalGuard removes. It reads both debug.log and the PHP error_log and shows them in wp-admin, so you never touch FTP or SSH to read your logs. On top of the raw tail it adds the things a flat file can’t:

• Grouping — identical errors collapse into one row with a count, so a noisy warning doesn’t hide a fatal.
• Search — filter by message, file, or function.
• Live tail — new entries appear as they happen; reproduce a bug in one tab and watch it land in another.
• Classification — fatals, warnings, and deprecations at a glance.

And it turns on file logging without you editing wp-config.php, so you don’t have to remember to flip WP_DEBUG back off later.

The short version

• Enable logging with WP_DEBUG_LOG (and keep WP_DEBUG_DISPLAY off on production).
• Reading the file means FTP, a host file manager, or SSH tail -f — none of them pleasant on a live site.
• A dashboard log viewer skips all of that and adds grouping, search, and a live tail on top.

Logs are the fastest way to a root cause. The easier they are to read, the faster you fix things.

FatalGuard puts your logs in wp-admin, free — no SSH required.