Watching more than AI limits
The same widget tells me whether my sites answer, whether my apps and jobs report in, and how their machines are doing.
The first two posts are about AI plan usage, because that is where Monizard started. These days the same widget also tells me whether my sites answer, whether my apps and scheduled jobs are still reporting in, and how the machines they run on are doing. This post is about how I use those parts.
| What | How it is checked | What counts as trouble |
|---|---|---|
| AI plans | Monizard reads each plan's usage on a refresh. | A window close to its limit, or use far ahead of the day. |
| Sites | Monizard asks each site whether it answers, on a schedule set per site. | A failure confirmed from a second place. |
| Apps and scheduled jobs | Each one reports in with a signed report that says when the next is due. | A report that is late. |
| Machines | They report in the same way as apps. | Going quiet, or running short of disk or memory. |
Sites
Monizard asks each of my sites whether it answers, on a schedule I set per site, and shows the result with the same green and red it uses for the dials.
A single failed check is a poor reason to raise an alarm. Networks drop a request now and then, and a check that comes from one place can fail because of that place and not the site.
So Monizard confirms a failure from a second place before anything alarms, as Figure 1 shows. When both agree, it is usually worth my attention.
Heartbeats
Some of my programs run without anyone watching them, such as a nightly job or a small service. A site check cannot see those, because they have nothing to visit.
Instead, each app reports in on its own schedule, using its own key. Each report is signed and says when the next one is due. If a report is late, Monizard raises an alarm.
Putting the due time inside the report matters more than it sounds. A job that runs once a week and a service that reports every few minutes need very different patience. Because each report says when to expect the next, Monizard does not have to guess how long silence is normal for each of them.
| Program | Its last report said | Silent for an hour |
|---|---|---|
| A nightly job | Next report in about a day. | Normal. Nothing to do. |
| A small service | Next report in a few minutes. | Late. The alarm is raised. |
Machines
The machines those apps run on report in the same way. When one goes quiet, or starts running short of disk or memory, it shows up on the widget next to everything else. More than once that has told me why an app went quiet before I went looking.
Why it is one tool
These look like separate jobs, but they ask one question: is something I depend on still fine? A plan nearing its limit, a site that stops answering and a job that misses its report all mean something needs attention before it becomes a problem.
I would rather have one place that answers that question, and one habit of glancing at it.
With a separate tool for each, I would be checking several places, and in my experience the one I forget to check is the one that fails.
The shape of the readings carries over too: usage readings already have a stale flag and a way of saying how old they are. A late heartbeat is the same idea applied to a program, and a failed check that has not been confirmed is another kind of unknown. Reusing that vocabulary keeps the tool small.
Agents see it too
The agent-facing file and command carry these readings alongside the usage ones, so a script that already reads monizard-usage can learn that a site is down or a job is late without a new tool. When something fails, my agents hold a release to that site or go and find out why a job went quiet. As with usage, the advice stays advice, and the person or agent using it makes the call.