Check a server and its backup
Find out what is running, whether its backup completed and what needs attention.
Two things to check
A running app and a completed backup are different pieces of evidence. Check both. You need permission to read the server status and the backup records, including the copy stored away from that server.
The method
Check disk space, memory, load and whether the web server, database and apps are running. Confirm the latest backup completed and was copied off the server. Write a dated report with the evidence for each check. Raise failed checks for review. Keep the decision and permission to repair separate from the checker.
Check the result
The report shows what passed, what failed and where the evidence came from. To run it on a schedule, you need a configured check script and reporting destination. A successful copy alone does not prove that a backup can be restored.
How we use it at Pitch
At Pitch, the board is our shared work log. An assistant is software that follows our instructions with access to agreed tools. A watcher checks for changes and reports them; a worker runs a configured routine. Those roles need explicit instructions, access and permissions. Context and boundaries Server health is the workflow for the thing nobody checks until it breaks. The decisions that stay with us are what to fix, and when. Checking every morning, and noticing when something is wrong, belong to the server itself and a watcher . The setup A check script on the server that runs after the nightly backup and writes its own row to the same board as everything else. The watcher in the morning run that reads it and raises anything that failed. And one design choice that makes it safe: the watchers can read and report but cannot touch the server, so any fix is proposed to us and made by us. Our sequence Every morning, after the backup, the server runs its own checks: disk, memory, load, the web server, the database and each app. It confirms the backup ran and was copied off the server. It writes the result to the board itself. The watcher reads the report and turns any failed check into an item in the morning briefing . The principle The server reports on itself every morning, in writing. A check nobody has to remember is a check that happens. What stays with a person We still decide what to fix and how. Remembering to look, and reading the numbers, stopped being ours. What it took us The check script and its daily report came first, as an email. Writing the result to the board came with the September rebuild, and a second watcher, which grades each report and checks the backup against separate evidence, is partway through a trial of fourteen reports before its grading counts for anything. How the process began We'd log in to the server when we thought of it. Check the disk, the memory and the load. Check that the web server, the database and each app were running. Check that last night's backup had run and been copied off the server. Most days everything was fine, so the checking drifted.