Status Page with Attitude: When My Homelab Started Roasting Its Own Downtime

Every homelab person I know has the same dirty secret: the status page is a lie. Mine was a wall of green dots that updated maybe when I remembered, which is to say, after something had already been broken long enough for my wife to ask why the photo sync wasn't working.

So I did what I do in this lab — I over-engineered a fix. I gave every service a voice. Literally. Each container now writes its own incident reports, in English, using a small local LLM. The catch nobody warns you about: once a machine can explain itself, it will eventually develop opinions.

The Boring Part First: The Plumbing

The skeleton is unremarkable, which is how you know it'll survive. Uptime Kuma watches the services. A webhook fires on state change. A tiny Python worker catches the event, grabs the last few minutes of logs from the container, and hands the whole mess to a quantized model running on a spare mini PC in the closet — same closet as the servers, because I refuse to pay for API calls on a hobby that already eats my weekends.

The prompt is where the magic lives. Roughly: "You are the service that just went down. Using the attached logs, explain in two sentences what happened, what you're doing about it, and whether the human needs to care."

That last clause matters more than you'd think. Most outages are a Postgres restart or a DNS blip. The status page needed a way to say "nothing to see here" without paging me at a kid's soccer game.

The Reports Were Good. Suspiciously Good.

The first week, I was genuinely impressed. When my reverse proxy choked on a cert renewal, the page read:

"Cert renewal hit a rate limit because someone (not me) restarted me four times testing firewall rules. Back in 30 minutes once the ACME cooldown clears. No action needed, Aleks."

That's better than half the status pages of companies with Series B funding. It named the cause, the fix, the ETA, and the responsible party. The logs-to-English pipeline was doing real work — I'd argue an LLM summarizing a log tail is one of the few genuinely useful LLM jobs out there, right next to "explaining someone else's regex."

Then It Got Comfortable

Around week three, the tone shifted. A disk on the NAS backup box filled up during a large Time Machine-style backup, and the report came back:

"The backup volume is full because someone pointed a decade of family photos at a 500GB drive and called it a day. I'll rotate the oldest snapshots. Maybe invest in a bigger disk? Just a thought."

I laughed. Then I paused. Because two days later it referred to a crashed Jellyfin instance as "dying dramatically, as is tradition," and my wife — the only other person who reads this page — asked why the server was being "passive-aggressive at us."

Here's the thing about personality in infrastructure: it's charming exactly twice. After that it's noise, and noise in a status page is worse than hostility. The whole point of the page is to answer one question fast — is anything actually broken, and is it my problem? Sarcasm adds a parsing step to every read.

Tuning the Dial

I ended up with a three-tier system, and honestly, this might be the most reusable idea in the whole build:

1. Severity drives tone. The prompt includes the check's priority. Critical services get flat, factual, boring reports. Homelab toys get a little flavor.
2. A hard word cap. Two sentences, enforced. LLMs ramble when you let them, and nobody needs a paragraph on why Pi-hole sneezed.
3. A banned-phrases list. No "as an AI," no "I apologize," no "just a thought." You'd be surprised how often the model tried to be polite at me.

The sass didn't fully go away. The Postgres container still gets cheeky when the Raspberry Pi it lives on throttles in a heat wave — a very Midwest problem, that. But the critical path reads like a boring SRE wrote it, which is exactly what a critical path should sound like.

What I'd Tell You Over Coffee

The outage reports turned out to be the least interesting part. The real win is that writing for a human forced the system to diagnose before reporting. A model that has to explain a failure in English has to actually read the logs, and about one in five incidents, it caught a root cause I'd have missed — like the time it noticed every crash followed a 2 AM cron job, a pattern I'd been ignoring for months because the individual failures looked random.

If you're going to steal this build, steal the constraint, not the personality. Make your infrastructure explain itself in two sentences or less. The wit is optional. The clarity isn't.

The status page is still mostly green. But now when it's not, it tells me why — in exactly as many words as it takes, and not one snarky sentence more. Mostly.