Your phone lights up the bedroom. Then it lights up again. And again. By the time you've found your glasses, the lock screen is a waterfall of red.

Welcome to the 3 AM production alert, the only meeting in the calendar that nobody scheduled and everybody attends.

A short play in five timestamps

03:04. "CRITICAL: CPU above 80% on web-2." You stare at it. Is 80% bad? Was it 79% yesterday? Nobody knows. The person who set the threshold left the team some time ago.

03:05. Same alert again. And again. Each check sends a fresh notification, so the alert is now mostly an alarm clock with opinions.

03:09. Laptop open. You find the logs. The relevant line says: Something went wrong. That's it. No user, no request, no job, no hint.

03:20. You remember there was a document explaining what to do. It's in a wiki. Somewhere. Under a page called "Misc (new)".

03:31. The CPU drops back to normal on its own. Nothing was broken for users. You did all of this for a scheduled report that runs at 3 AM every night. You go back to bed and lie awake thinking about your life choices.

What went wrong (spoiler: not the server)

❌ The alert fired on a cause (high CPU), not a symptom (users getting errors or slow pages).

❌ It woke a human for something that didn't need a human at all.

❌ It repeated itself instead of grouping into one notification.

❌ It didn't say what to do, or link to anything that did.

❌ The logs had a message but no context, so finding the cause meant guessing.

❌ The "runbook" was buried, out of date, and written for a server that no longer exists.

Notice that none of these is a code bug. The system was fine. The alerting was broken, and broken alerting has a real cost: people learn to ignore it. And the night the alert really matters, it's just one more red notification in the pile.

What actually fixes it

✅ Page on symptoms, log the causes. Wake someone up for "error rate is high", "checkout is failing", "the queue has stopped draining". High CPU, a full-ish disk or a slow query can go to a dashboard or a daytime ticket.

✅ Every page must be actionable. If the honest response to an alert is "wait and see", it shouldn't be a page. Either make it actionable or downgrade it.

✅ Two levels, not ten. "Wake me up" and "look at it in the morning". Anything in between tends to get treated as one or the other anyway.

✅ Group and deduplicate. One incident, one notification, with updates in the same thread.

✅ Put the runbook link in the alert itself. What this alert means, how to confirm it's real, the first three things to check, and who to call if you're stuck. Short, and next to the alert, not three clicks away.

✅ Log with context. A log line without context is a riddle. Attach a request ID and the user to every log line automatically, so you can follow one request from start to finish. Laravel's Context facade (added in Laravel 11) makes this almost free, and the data even follows the request into queued jobs:

class AddRequestContext
{
    public function handle(Request $request, Closure $next): Response
    {
        Context::add('request_id', (string) Str::uuid());
        Context::add('user_id', $request->user()?->id);

        return $next($request);
    }
}

// Later, anywhere: the context is attached to the log entry automatically
Log::error('Payment webhook rejected', ['reason' => $reason]);

✅ Review every page afterwards. After each out-of-hours alert, ask one question: should this have woken someone up? If not, change the alert that week, while the pain is fresh.

The happy ending

Good alerting is boring. Your phone stays quiet most nights, and when it does buzz, you trust it, because it has never cried wolf. The alert tells you what's wrong, the link tells you what to do, and the logs tell you exactly which request failed.

That's the dream. Most of us are somewhere between that and the waterfall of red.

What's the most useless alert that has ever woken you up? I'll start the bidding with "CPU above 80%, no further details".