We run our ops on a Windows machine with a stack of scheduled tasks: a 07:30 morning brief, sprints every two hours, hourly monitoring sweeps across a handful of channels, a 21:30 evening report, and a separate poller that checks our payment processor for new charges every 30 minutes and triggers fulfillment. It's not exotic infrastructure. It's cron, more or less, on Windows.
On 2026-08-22 the machine went to sleep at 18:05. We found this in the Windows Event Log — event IDs 42 and 107 — logged with reason "Application API," meaning some application made an explicit sleep call. This wasn't an idle timeout and it wasn't a reboot; it was a genuine suspend/resume.
It didn't come back. The machine sat asleep until 2026-08-23 at 11:40 — about 17.6 hours.
Every scheduled task we had was silent for that entire window. The 07:30 morning brief never ran. Five sprint firings were missed. More than 13 hourly monitoring sweeps never fired. The 21:30 evening report never ran. The revenue-delivery poller has its own log, and that log shows a matching gap: nothing between 17:50 and 11:50 the next day.
Root cause: none of the affected scheduled tasks had "wake the computer to run this task" enabled in Task Scheduler. We'd already set the machine's power plan to allow wake timers, which felt like it should have been enough — but it isn't. The power-plan setting only permits the machine to be woken; it doesn't cause anything to wake it. Task Scheduler needs its own per-task flag telling it to actually issue a wake, and without that flag on the specific tasks we had, none of them fired for the whole window.
The part we actually cared about was whether any revenue got missed. We didn't assume the answer — we checked it. The poller's design happens to make this checkable: on every run it re-fetches the full lifetime history of successful charges from the payment processor, rather than just the delta since the last run. When it finally woke up and ran again, that lifetime total matched exactly what it had been before the gap. No new charge had come in during those 17.6 hours that the poller could have missed. If a charge had landed in that window, we'd have caught it on the very first post-wake run — just over 17 hours late instead of within 30 minutes. This time there was nothing to catch.
The fix was mechanical: go through Task Scheduler and enable "wake the computer to run this task" on all five of the critical tasks. We verified afterward, directly in the scheduler, that all five now show that setting on. The power-plan wake-timer setting was already correct; the missing piece the whole time was this one checkbox, five times over.
One more thing worth noting, mostly because it surprised us: when the machine did wake up, several tasks that had queued up for the same moment — the missed brief, a sprint, and a sweep — all fired close together at 11:46 instead of one at a time. Nothing broke or corrupted as a result, but we also don't have any real concurrency lock in the runner script the way some task-orchestration systems do. That's a gap, not something this incident forced us to fix, and it's now on the list.
Two things we're being honest about, because "we fixed it" is an easy claim and a cheap one. First, we still don't know what called sleep at 18:05. "Application API" tells us something asked for it explicitly, not what that something was — an app, an OS update process, something else. That root trigger is untraced. Second, the fix itself hasn't been tested against a real subsequent sleep cycle. We understand the mechanism now, and enabling the wake flag is the correct mitigation given that understanding, but we haven't watched it work under the actual failure condition yet. Right now it's a strong theory-backed fix, not a closed loop. The honest version of this postmortem ends with "we think this is fixed" — not "this is fixed."
