Every Server Grades Its Own Health: The SQL Report That Runs Itself

I used to open a chat window and ask my AI assistant to health-check the database fleet whenever I remembered to. It worked great — but "whenever I remembered" is a lousy schedule. So I taught the same health check to run itself: every production database server now grades its own health once a week and drops a color-coded report card into our team channel. No one logs in. No one runs anything. Here's the story — and a real (anonymized) report at the end so you can see exactly what lands in the inbox.

The Starting Point: A Good Report Nobody Scheduled

I'd already built a read-only assistant that could inspect our SQL Servers — ask it "how's the fleet doing?" and it runs a battery of safe, look-but-don't-touch checks and hands back a scored report. Genuinely useful. The catch was that it only ever ran when I asked. A weekly health baseline shouldn't depend on a human remembering to request it on a Monday.

The tidy answer would be "just put it on a timer on the servers." But production database servers are deliberately bare — we don't install extra software on them, because every extra thing is one more thing to patch and secure. I wasn't going to add a bunch of tooling to the box running live customer data just to send an email.

So the report had to become something those locked-down servers already know how to run on a schedule, with nothing new installed: a single self-contained program, kicked off by the database's own built-in scheduler.

The Idea I'm Proudest Of: One Health Check, Two Faces

Here's the decision that made the whole thing trustworthy. The scheduled version and the "ask the assistant" version are not two separate tools that happen to look alike. They're literally the same health check underneath — the exact same code that produces the report.

The scheduled program is just that engine with a different front door: no chat, no server, it simply runs the checks and writes the report. That means the email that lands every Monday is identical to what I'd get if I asked the assistant live, right now.

Why that matters: the moment a "scheduled version" becomes its own copy of the logic, the two slowly drift apart — the live answer says one thing, the weekly email says another, and you stop trusting both. By keeping one engine with two faces, there's nothing to keep in sync. There's only one report; it just shows up two ways.

What the Report Actually Checks

Every run works through 43 read-only checks, grouped into eight plain-English areas of database health:

• Availability — are the databases up, and are the failover copies healthy?

• Performance — memory, parallelism, and what the server spends its time waiting on.

• Recoverability — are backups current, and has the data been integrity-checked?

• Reliability — early-warning signs like log-file bloat or an ID column about to run out of numbers.

• Security — who has the keys, and how connections authenticate.

• Configuration — instance settings and whether the build is current.

• Maintenance — unused or duplicate indexes quietly costing you.

• Host / OS — disk space, power plan, and the machine underneath it all.

  
  

Every check comes back Pass, Attention, Fail, or Info, and those roll up into a single health percentage — a failing backup drags the score down far harder than a cosmetic setting. All of it comes from a well-loved, open-source toolkit that DBAs have trusted for years; I just wired it to run itself and never let it do anything but read. (One nice detail: the toolkit has a "verify backup" check that works by secretly restoring the backup — a write — so it's switched off and replaced with a read-only "when did the last backup finish?" check instead.)

How It Ships and Runs Itself

Two plain-language pieces, no ceremony:

1. It's packaged as one self-contained program. The whole health check is bundled into a single Windows executable — everything it needs to run is inside it. Drop that one file on a server and it just works; there's nothing to install and nothing to keep updated on the box. (It's a chunky file precisely because it carries everything with it — that's the trade I wanted.)

2. The database's own scheduler runs it weekly. On each server I set up one scheduled job that, every Monday morning, runs the program against that server and emails the result to our team's Slack channel. It runs under the server's own trusted identity — so there's no password stored anywhere — and it works whether that node is the primary or a standby copy. One server, one report, one tidy Slack message. If the job itself ever fails, it pages the on-call person instead of quietly going dark.

Rolling it out is deliberately boring: copy one file to a server, run a small setup script once, move to the next. I did that across a number production database servers in four regions (a mix of two cloud providers). Now the whole fleet reports its own health every week, with no central system that could break and silence everyone.

What Actually Lands in the Inbox

Enough description — here's a real weekly report, with the server names, addresses, and internal details anonymized. This is exactly the format that arrives in Slack every Monday: a headline health score, a card per category, and a findings table that tells you not just what's wrong but what to do about it.

… plus ~31 more informational checks (AG topology, error log, logins, indexes, trace flags, OS, and so on). Server names, IPs, and internal database names anonymized.

You can read that in five seconds: this server is fine on availability and performance, but it's red on disk space and needs attention on log fragmentation and its admin list. And crucially, every "Fail" comes with the fix, not just the complaint.

Why This Shape Is Safe by Default

Everything I care about is built in, not bolted on:

• It can only look, never touch. It's the same read-only health check as the live assistant — there's simply no path in it that can change anything. A job that runs unattended every week is exactly the thing you want to be incapable of causing harm.

• No passwords anywhere. It runs under the server's own trusted identity, so there's no secret stored in the job or in a file to leak.

• Nothing extra on the box. One self-contained file, run by the scheduler the server already has. The production host gains no new software to worry about.

• It fails honestly. A broken run pages a human; it never invents a green report. And because each server mails its own result, a failover over the weekend never leaves the report pointing at the wrong machine.

  
  

What I'd Tell You If You're Building One

Share the engine, change only the front door

The best decision was refusing to write a second "report version." One health check, two ways to reach it. The live answer and the weekly email can't disagree, because they're the same thing.

Meet the server where it already is

A locked-down production box will happily run one self-contained file on a schedule and will resist anything that smells like installing tools. Package to what the server already does, instead of dragging your workshop onto it.

A report you can read in five seconds beats a perfect one nobody opens

The score, the color, the eight cards — that's what makes people actually glance at it every Monday. The depth is there when you need it, but the headline does the work.

Closing

The clever part here isn't the program — it's that the program is the same health check I used to run by hand, just wearing a different face so it can run itself. An AI assistant built the report. A single self-contained file made it portable. The database's own scheduler put it on every server, every Monday. Now the fleet grades its own health and drops the result in our channel — read-only, password-free, and identical to what I'd get if I asked live.

It started as a report I had to remember to run. It ended as one the servers run for me.

The tool described here is the scheduled face of a read-only SQL health assistant for a multi-region database fleet — the same trusted, look-but-don't-touch checks, packaged as a single self-contained program and run weekly by each server on itself. Built with Claude Code. If you're giving AI-built tooling a safe, unattended home in production, feel free to reach out.