Memory Ceiling Dropped from 40.91 GB to 36.66 GB After Reboot

Two months of updates were sitting on a server, installed but doing nothing until the machine restarted. It had put that restart off for weeks. We wrote down how long the website would be down, and the number we wrote was a guess.

Two guesses in a row

An early version of the plan said about three minutes. It read like a fact, because that is how downtime windows usually read. Then we checked what was actually waiting on the machine, and three minutes looked too small for two months of updates. We changed the plan to a wide range of 20 to 45 minutes. We also added a note about what happens if someone trusts the old number: they stand there at minute 20, unsure whether the machine has died.

Neither number had been measured. One was too small and the other turned out too large.

What the run showed

The restart happened early in the morning. One of us pressed the button. An AI agent did the watching from outside the machine, recording what the site did. Partway through, that agent session kept failing on errors from the AI service, and a second one took over the watch.

The site was down for about two minutes. Then it went down again for about two more, without anyone touching anything. That made about four minutes of outage across two restarts, nothing like 20 to 45.

The second restart was in no version of the plan. The machine’s own update installer had queued a follow-up restart to finish the job. That is normal behavior once you know to look for it, but nobody had looked, because nobody had run this machine through this procedure before. Whoever was watching would have taken the second drop for a failure.

Four corrections to the written procedure

The same morning, the written procedure got four changes:

• A warning that the machine restarts twice, how to tell the second restart from a real failure, and a rule not to run the after-restart checks between the two.
• The wider range, kept, with the one real measurement added as a data point next to it instead of replacing it.
• A note that the machine’s memory ceiling, the most memory it reports it can use, had changed by itself across the restart, from 40.91 GB to 36.66 GB. A before and after comparison should expect that.
• Three warnings that appear on every start-up of that machine, before and after, listed as known noise so nobody chases them.

We also added a check that the updates had actually installed. The machine’s “restart needed” marker clearing does not prove they landed.

What the agent did and what we did

The AI agent could watch, time the outage and write down what it saw. It could compare the run to the plan and list where the two disagreed. We chose the day, pressed the button and decided whether the plan was fit to rely on. Judging that “about three minutes” was not good enough to act on took a person reading the situation.

The procedure now carries one measured figure, about two minutes per restart, recorded as a data point from a single run next to the wide estimate. That is as much as the next person is entitled to trust.

dxdev LESSON · paste into your AI agent

LESSON: Label every number in a plan as measured or guessed, and say which run it came from

WHAT TO SHARE:
A de-identified copy of a checklist, plan or procedure that contains durations, counts or thresholds, and anything you know about the last time it was actually carried out.

ASK YOUR AGENT TO:
1. List every number in the document and mark each one as measured, estimated or unknown.
2. For each measured number, say what run or observation it came from and how many times.
3. Point out any step that assumes something happens once when it could happen more than once.
4. Suggest what to record during the next real run so the guesses can be replaced.

RETURN:
A table of numbers, their status and their source, plus the steps that assume a single occurrence.

BOUNDARY: Do not edit the document or run any step in it. A person decides which numbers to trust and updates the plan.