PHP Debugging Without Xdebug

There's a moment every developer knows well. Three in the morning. Your code isn't working. You reach for Xdebug, and it's not there—or it's broken, or it's disabled in production, or you're stuck on a shared hosting environment that doesn't support it. What then?

This is the question that shaped how I learned to debug. And honestly, it made me a better developer. Not because Xdebug is bad. It's wonderful. But because constraints force creativity, and sometimes the most valuable debugging skills come from working without your favorite tools.

Let me walk you through this. I'm not here to convince you that Xdebug doesn't matter. I'm here to show you that you have more power in your hands than you probably realize.

The philosophy behind manual debugging

Before we talk techniques, let's think about what debugging actually is. It's not pressing a button and watching variables. It's asking questions. Why did this happen? What did I expect? Where does reality diverge from expectation?

Xdebug answers these questions fast. Manual debugging makes you ask them deeply.

When you can't step through code line by line, you have to think like the code does. You have to trace execution paths in your mind. You have to predict what should happen and then verify it. This mental model—this internalized understanding of how your code flows—is something many developers never develop because they learn to trust the debugger instead.

I'm not being romantic about it. I'm describing something real. Developers who've spent time debugging without advanced tools often catch bugs faster than those who haven't, because they understand their code at a cellular level.

That said, let's be practical. You need strategies. You need tools that exist within PHP itself. You need patterns that work reliably.

Echo, print, and var_dump: the trinity

Let's start with what you probably already know, because there's a reason it's still the foundation. When you need to see what a variable contains, you have three immediate options:

echo is your fastest check. It outputs a value. No overhead. No formatting. Just the raw content.

print does almost the same thing, but returns 1, so you can use it in expressions. Rarely necessary, but good to remember.

var_dump() is the heavyweight. It shows you type, structure, and content. When you're confused about what something actually is, var_dump is honest. It tells you everything.

The power of these isn't in their sophistication. It's in their availability. They work everywhere. Shared hosting. Docker containers. Production servers (though you'd want to be careful). They don't require extensions or configuration.

I remember debugging a Laravel application once where something was null when it shouldn't have been. I couldn't install Xdebug because the hosting was restrictive. So I added var_dump at three key points in the execution path. I saw exactly where the value became null. Took five minutes. Then I fixed it.

The mistake is thinking echo and var_dump are crude. They're not. They're direct. They're reliable. They work.

Structured logging: debugging's quiet conversation

Here's what changed everything for me: realizing that debugging isn't just about finding bugs in the moment. It's about creating a conversation with your code over time.

This is where logging comes in. And logging properly is an art.

Consider this. Instead of scattering var_dump statements everywhere and cleaning them up later, you write to a log file. A structured log. A conversation. You can read it after the problem occurs. You can search it. You can share it with teammates.

<?php
// Simple file logging
$debug_log = fopen('/tmp/debug.log', 'a');
fwrite($debug_log, date('Y-m-d H:i:s') . " - User ID: " . $user_id . "\n");
fwrite($debug_log, date('Y-m-d H:i:s') . " - Query: " . $query . "\n");
fclose($debug_log);

Or if you're using a framework, leverage its built-in logging. Laravel has Log. Symfony has the monolog package. These aren't luxuries. They're infrastructure.

<?php
// Laravel example
Log::debug('User attempting to update profile', [
    'user_id' => $user_id,
    'changes' => $changes,
    'timestamp' => now()
]);

The advantage here is subtle but powerful. Your debugging doesn't interrupt your code flow. It doesn't change behavior. And it persists. You can come back to it. You can analyze patterns.

I've caught race conditions this way. Timing issues that would never show up in a debugger because the debugger changes timing. Logging showed me the sequence of events. The race became visible.

Error logging and PHP's error_log

PHP has a built-in function that most developers forget about: error_log().

This function writes to your system's error log. On most systems, that's defined in php.ini as error_log. You can write to it manually.

<?php
$data = some_function_that_might_fail();
if ($data === false) {
    error_log("Failed to fetch data. Error details: " . print_r($data, true));
}

The beauty of error_log is that it's configured separately from your application. Your logs go to a specific place. You can tail them in real time on production. You can set up log aggregation. You can monitor them.

In production environments, this becomes critical. You can't use echo. You can't use var_dump. It breaks the response. But error_log writes silently to a file you control.

Understanding error reporting and display_errors

Before you start logging aggressively, understand that PHP has its own error reporting system. By default, many hosting providers disable error display (for security—they're right to). But you can control what gets logged.

<?php
// At the start of your application
ini_set('display_errors', 0); // Don't display to users
ini_set('log_errors', 1); // Do log them
ini_set('error_log', '/var/log/php-errors.log'); // Where to log
error_reporting(E_ALL); // Report everything

This setup means that every notice, warning, and error goes to your log file, but users never see it. Your application stays clean. Your debugging stays silent and comprehensive.

I've found hundreds of issues this way. Issues I didn't know existed because they only showed up as notices. Issues that could become problems.

Assertions and assertions for debugging

PHP has a feature called assertions. They're conditionally enabled. They let you make claims about your code's state, and if those claims fail, they raise an error.

<?php
assert($user !== null, "User should exist at this point");
assert($user->id > 0, "User ID should be positive");

Assertions don't run in production (by default). They're development tools. But they're powerful development tools because they make your assumptions explicit. They document what you believe to be true. And they fail loudly if you're wrong.

I use assertions at function entry points, after queries, and at critical state transitions. They catch assumptions that turned out to be false. They catch edge cases I didn't think of.

The humble exit and die statements

Sometimes you need to stop execution and see what happened up to that point. This is what exit() and die() do.

<?php
$result = database_query($sql);
if (!$result) {
    echo "Query failed: " . $last_error;
    die;
}

This is crude, yes. But it's effective. It stops execution. It lets you see state at that moment. You add this during debugging. You remove it when you're done.

The key is discipline. Use it deliberately. Don't leave it in production code.

Backtrace and stack traces

When something goes wrong, you want to know how you got there. What called this function? What called that? This is called the stack trace, and PHP can give it to you.

<?php
function problematic_function() {
    // Something went wrong
    echo "<pre>";
    debug_print_backtrace();
    echo "</pre>";
    die;
}

Or capture it:

<?php
$trace = debug_backtrace();
foreach ($trace as $call) {
    echo "Called from: " . $call['file'] . " line " . $call['line'] . "\n";
}

The backtrace is your roadmap. It shows you exactly where you are. It shows you how deep you are. It shows you what the execution path was.

Performance profiling without tools

Sometimes the bug is speed. Your code works, but it's slow. Without Xdebug's profiler, how do you find where the time is going?

Microtime. It's your friend.

<?php
$start = microtime(true);
perform_expensive_operation();
$end = microtime(true);
echo "Took " . ($end - $start) . " seconds\n";

This is manual, yes. But you can place these measurements around specific functions and sections. You can narrow down where the slowness lives.

<?php
$times = [];

$times['query_start'] = microtime(true);
$results = $database->query($sql);
$times['query_end'] = microtime(true);

$times['process_start'] = microtime(true);
$processed = process_results($results);
$times['process_end'] = microtime(true);

echo "Query: " . ($times['query_end'] - $times['query_start']) . "s\n";
echo "Processing: " . ($times['process_end'] - $times['process_start']) . "s\n";

You're doing binary search on performance. This section is slow or this section is slow. Gradually you find the bottleneck.

Memory usage tracking

Similarly, you can track memory:

<?php
echo "Peak memory: " . (memory_get_peak_usage(true) / 1024 / 1024) . " MB\n";
echo "Current memory: " . (memory_get_usage(true) / 1024 / 1024) . " MB\n";

Memory leaks exist. Objects not being garbage collected. Circular references. Large arrays being kept in memory. Memory tracking helps you find them.

Unit tests as debugging

Here's something that might seem unrelated but absolutely isn't: writing tests is a form of debugging. When you write a test, you're making assumptions explicit. You're saying: "Under these conditions, this function should do this."

Run the test. Does it pass? Then you know that condition and outcome work together.

Does it fail? Now you have a reproducible scenario. You can debug it in isolation. You can add logging. You can add assertions. You can run it repeatedly and confirm the fix.

Tests are debugging that persists. They're bugs you've already found and documented so you never find them again.

Error handling as a debugging tool

This might sound strange, but proper error handling is debugging. When you catch an exception, you can log it with context:

<?php
try {
    $data = perform_risky_operation();
} catch (Exception $e) {
    error_log("Exception in perform_risky_operation: " . $e->getMessage());
    error_log("Stack trace: " . $e->getTraceAsString());
    error_log("Context: user=" . $user_id . ", request=" . $_SERVER['REQUEST_URI']);
    // Handle the error
}

This catches problems before they become invisible failures. It documents why something failed. It gives you the information you need to fix it later.

Creating a debugging checklist

Over time, I've learned that having a checklist helps. When something's wrong and Xdebug isn't available, I go through this:

• Check error_log and PHP's error reporting
• Add error_log() statements at key decision points
• Verify assumptions with var_dump()
• Check database queries are executing correctly (log the SQL)
• Measure time and memory to find performance issues
• Check for exceptions being silently caught
• Review recent code changes
• Look at browser console for JavaScript errors
• Verify environment variables are set correctly
• Test with different input to isolate conditions

This process works. It's slower than Xdebug, yes. But it's systematic. It forces you to think. And it works everywhere.

The learning that sticks

Here's what I want you to understand. Learning to debug without Xdebug teaches you something that Xdebug can't. It teaches you skepticism. It teaches you that you can't always trust what you think is happening. It teaches you to verify. It teaches you to question.

These skills transfer. When Xdebug is available, you use it more effectively because you understand what you're looking for. When it's not available, you have backup strategies that work.

The developers I've known who are best at finding bugs are usually the ones who've worked in environments where they had to be creative. They learned that debugging is thinking. Xdebug is a tool that helps you think faster, but the thinking itself is the core skill.

You're closer to mastery of debugging than you probably think. You already have var_dump. You already have error_log. You already have die and exit. You already have microtime. You already have stack traces and assertions.

What you need is confidence to use them. What you need is understanding that bugs are learnable. That they follow patterns. That with observation and patience, they reveal themselves.

The next time you're without Xdebug, don't see it as a limitation. See it as an opportunity to deepen your understanding of how your code actually works. See it as a chance to build muscle memory in problem-solving. See it as time spent becoming a better developer.

Because that's what it actually is.