I have a lot of tools at home: the server, the apps on it, T3, and apps I built. Each has its own address. So I made one page with all of them. It only opens on my private network, and its data refreshes every five minutes.
The page is an app of its own, and it’ll get a full post later; I’ll link it here. This post covers the jobs that feed it.
The check: every five minutes
A read-only script goes through every tool on a list and checks that it’s up. The checks are kept for about a week, so the page can show me:
- Whether each tool is up or down, and how long it’s been down.
- How often it was up over the week, worked out from those checks, with an hour-by-hour strip for the last day.
- The latest times it went down.
There’s also a board like an airport departures board for the scheduled jobs: when each last ran, whether it worked (from the job’s own result and status file), and when it runs next. Next to it are the other jobs’ status files, like backups, the guard and machine health, plus the computer’s disk and memory.
If one of the extra sections fails, it says so, and the basic checks carry on.
The server: every half hour
A second job asks the server at home for a read-only report: how much storage is used, the fullest disk, the parity status and the internet speed. The page shows them.
The server is flagged when something is actually wrong: a failed parity check, a nearly full disk, or a reading that failed or came back incomplete.
How to set one up
Build me a start page for my home tools:
1. A tools.json file with every tool: its name, its address, and how to check it's up.
2. A read-only script that checks each tool every five minutes and keeps the results for a week in a SQLite database.
3. A static HTML page showing each tool: up or down, since when, and how much of the week it was up.
4. A section for the scheduled jobs: last and next run from systemctl --user list-timers; the service's state from systemctl --user show <job>.service -p Result -p ActiveState; and each job's own status file, if it has one, checked for allOk and how fresh it is. Show running, unknown or stale clearly, never as success.
5. If one part fails, write that it failed and let the rest of the page carry on.
6. Any number you couldn't read, show as "not read", never as zero.
Keep it on your private network, through Tailscale for example, not on the internet.
What I learned
- Unread isn’t zero. If the page can’t read the storage, it says “not read”, not 0%. A zero reassures you about something you don’t know.
- Extras can’t take down the basics. If an extra section fails, it says so in its own place, and the up/down checks still run.
- A problem has to be a real problem. If everything turns red, you miss the red that matters.
Tools
Next in the series: the school app.