Uptime Monitoring
debt(d7/e3/b3/t7)
Closest to 'only careful code review or runtime testing' (d7). The absence of uptime monitoring or a misconfigured health endpoint (always returning 200) is not caught by any compiler, linter, or standard SAST tool. Tools listed (UptimeRobot, Pingdom, StatusPage, BetterStack) are external services that must be deliberately set up — their absence is invisible until a real outage occurs and no alert fires. Code review might catch a trivially broken health endpoint, but regional blind spots or shallow checks slip through easily.
Closest to 'simple parameterised fix (replace pattern with safer alternative)' (e3). The quick_fix describes setting up an external monitoring service — a small, bounded task. Fixing a shallow health endpoint to actually verify dependencies (DB, cache, etc.) may touch a few files but is still contained within one component. Slightly above e1 because multiple common_mistakes (geographic coverage, alert escalation, deep-check endpoints) may each require a small configuration or code change.
Closest to 'localised tax' (b3). The monitoring setup and health endpoint live in a specific infrastructure/observability layer rather than permeating the entire codebase. Applies only to web contexts. Once set up correctly, the rest of the codebase is largely unaffected, though ongoing alert routing and status page maintenance impose a small persistent operational tax.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The canonical misconception is precise and dangerous: an HTTP 200 response is widely understood as 'everything is fine,' yet the health endpoint can return 200 while the database, cache, or payment provider is completely broken. This directly contradicts the developer's reasonable mental model. Multiple common_mistakes reinforce this — checking only the homepage (which may be cached), monitoring from a single location, and ignoring alert escalation — each represents a plausible-but-wrong implementation that provides false assurance.
Also Known As
TL;DR
Explanation
Synthetic monitoring: external agents (Pingdom, UptimeRobot, Checkly, AWS CloudWatch Synthetics) send HTTP requests on a schedule and alert on downtime or degradation. Checks: simple HTTP ping, multi-step flows (login, checkout), API endpoint verification. Real User Monitoring (RUM): instruments actual user traffic — measures real-world performance, captures Core Web Vitals, detects regional issues. Both complement each other: synthetic catches outages quickly (1-minute intervals), RUM shows real user experience. PHP health endpoint: respond 200 only if DB, cache, and critical services are all healthy.
Common Misconception
Why It Matters
Common Mistakes
- Health endpoint that always returns 200 regardless of dependencies.
- Monitoring only from one geographic location — regional DNS or CDN issues go undetected.
- No alert escalation — single point of contact for 3am alerts causes burnout.
- Checking homepage only — deep application functionality (checkout, API) may be broken while the homepage serves from cache.
Code Examples
// Shallow health check — always 200:
// GET /health
echo json_encode(['status' => 'ok']); // Returns 200 even when DB is down
http_response_code(200);
// Uptime monitor: all green
// Reality: every user request is failing with 500// Deep health check:
GET /health → 200 if all healthy, 503 if any dependency down:
$checks = [
'database' => fn() => $pdo->query('SELECT 1'),
'cache' => fn() => $redis->ping(),
'queue' => fn() => $horizon->isRunning(),
];
$failed = [];
foreach ($checks as $name => $check) {
try { $check(); } catch (\Throwable) { $failed[] = $name; }
}
$healthy = empty($failed);
http_response_code($healthy ? 200 : 503);
echo json_encode(['status' => $healthy ? 'ok' : 'degraded', 'failed' => $failed]);