How to Monitor PHP Application Uptime

PHP powers a significant share of the web — from WordPress and Drupal sites to custom applications built with Laravel, Symfony, and CodeIgniter. While PHP itself is stable, PHP applications can fail in ways that are specific to the language and runtime. This guide covers monitoring PHP applications for uptime and availability.

PHP Application Failure Modes

Understanding failure modes helps you monitor the right things:

• PHP-FPM process crash — PHP-FPM stops accepting FastCGI connections
• Memory limit exceeded — PHP process killed due to memory_limit exceeded
• Max execution time — Long-running scripts timeout
• Database connection failure — PDO/MySQLi can't connect to the database
• PHP parse error after deployment — Syntax error in deployed code causes 500 errors
• File permissions error — PHP can't read/write required files
• OPcache stale — Cached PHP bytecode serves old code after deployment
• Session storage failure — Session handler (Redis, database) unavailable

External HTTP monitoring catches most of these — a 500 error or blank page indicates the application is failing, regardless of the specific PHP-level cause.

Adding a Health Endpoint to PHP Applications

Plain PHP

<?php
// health.php
header('Content-Type: application/json');

$health = ['status' => 'ok'];
$status_code = 200;

// Test database connection
try {
    $pdo = new PDO(
        'mysql:host=' . DB_HOST . ';dbname=' . DB_NAME,
        DB_USER,
        DB_PASS,
        [PDO::ATTR_TIMEOUT => 3]
    );
    $pdo->query('SELECT 1');
    $health['database'] = 'ok';
} catch (PDOException $e) {
    $health['database'] = 'error';
    $health['status'] = 'degraded';
    $status_code = 503;
}

http_response_code($status_code);
echo json_encode($health);

Laravel

// routes/web.php
Route::get('/health', function () {
    $status = ['status' => 'ok'];
    $code = 200;
    
    try {
        DB::connection()->getPdo();
        $status['database'] = 'ok';
    } catch (Exception $e) {
        $status['database'] = 'error';
        $status['status'] = 'degraded';
        $code = 503;
    }
    
    return response()->json($status, $code);
});

WordPress

// Add to your theme's functions.php or a custom plugin
add_action('rest_api_init', function() {
    register_rest_route('health/v1', '/status', [
        'methods' => 'GET',
        'callback' => function() {
            global $wpdb;
            $db_ok = ($wpdb->get_var("SELECT 1") === '1');
            return rest_ensure_response([
                'status' => $db_ok ? 'ok' : 'degraded',
                'database' => $db_ok ? 'ok' : 'error'
            ]);
        },
        'permission_callback' => '__return_true'
    ]);
});
// Access at: /wp-json/health/v1/status

External HTTP Monitoring

Configure your uptime monitor to check your health endpoint:

Monitor: https://yourdomain.com/health
Expected status: 200
Content check: "ok"
Interval: 1 minute

Also monitor your main application URL with content verification:

Monitor: https://yourdomain.com
Expected status: 200
Content check: your page title or brand name

Content verification catches PHP errors that return 200 status but display error pages — common with custom error handling or error_reporting set to display errors.

PHP-FPM Monitoring

If you use Nginx + PHP-FPM (the most common production setup), monitor PHP-FPM's status endpoint:

# In your Nginx config
location /php-fpm-status {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

Check PHP-FPM status locally: curl http://localhost/php-fpm-status

This shows active workers, idle workers, and queue length — useful for detecting PHP-FPM pool exhaustion.

OPcache After Deployment

After deploying new PHP code, you may need to clear the OPcache to ensure new code is served:

# Via PHP CLI
php -r "opcache_reset();"

# Or via a deployment script
curl https://yourdomain.com/opcache-reset.php

Failure to clear OPcache after deployment means old code continues to run — which can cause application errors if the database schema changed.

WordPress-Specific Monitoring

For WordPress sites, monitor:

Monitor: https://yourwordpresssite.com
Content check: your site name or a stable HTML element

Monitor: https://yourwordpresssite.com/wp-login.php
Expected status: 200
Content check: "Log In"

The wp-login.php check verifies WordPress is functioning. Also set up:

• SSL certificate monitoring (Let's Encrypt with certbot is standard for WordPress)
• Domain expiry monitoring
• WordPress admin email as an alert contact

Alerting Configuration

Configure appropriate alerts for PHP application severity:

See how to set up downtime alerts for full configuration.

Deployment Best Practices for PHP

Monitoring can help you catch deployment-related PHP failures:

1. Deploy to staging first — test for PHP parse errors before production
2. Clear OPcache after deployment — prevents serving stale bytecode
3. Watch monitors after deployment — keep monitoring dashboard visible for 10 minutes post-deploy
4. Use a deployment health check — many deployment tools can ping a health endpoint as part of the deployment process to verify the new code is working before marking the deployment as successful

Monitor your PHP applications externally at Domain Monitor — detect failures before your users do.

Related Articles

• "How to Monitor Node.js Application Uptime"
• "Website Uptime Checker Free: Monitor Your Site Without Paying"
• "How to Monitor Cron Jobs and Scheduled Tasks"