It Was Resolved at 2 a.m. Why Did Your Scheduled Agent Page On-Call Again at 6?

An incident wakes the on-call engineer at 2 a.m. The engineer investigates, applies the fix, watches the service recover, and marks the ticket resolved. At 6 a.m., the phone buzzes again: a scheduled watchdog agent has paged on-call for the same incident.

Nothing new broke overnight. The engineer confirms the service is healthy and closes the page as a false alarm. The damage is already done. A person was woken for work finished hours earlier, and the next real page will be treated with a little less urgency. A scheduled agent pages for a resolved incident because it works from a snapshot, not from the current state of the world.

The page comes from a list, not from the incident

Most watchdog agents work through a list. Each run pulls open alerts, error counts, or failed checks from a monitoring tool, and pages on-call for anything that still looks bad. That list was correct when it was built. The problem is that resolution happens somewhere else.

The fix might sit in a ticket the agent never reads. The confirmation might live in a chat thread where the engineer wrote that the service recovered. The monitoring tool itself might still show the old alert as open because nobody cleared it, or because a new alert with a different ID was created for the same problem. The agent reads its own list, finds the incident still on it, and pages.

Timing makes it worse. A run that reads its list at 5:55 a.m. and pages at 6:00 a.m. can cross a resolution that landed in between. A run that reads a cached dashboard can page on data that is already out of date. When two runs overlap, the second can page on an incident the first already escalated, because neither run left a record the other could read.

A false page is not harmless noise

Every false page trains the team to doubt the next one. An engineer woken twice for resolved incidents is slower to respond the third time. When a real incident arrives, that delay is measured in downtime, not inconvenience.

A false page also creates duplicate work. The engineer must verify the system is healthy, check whether anything changed since the resolution, update the ticket, and tell the team the page was a duplicate. That is real work, done at the worst possible hour, for an incident that needed no work at all.

What the next run needs to know before it pages

Stopping duplicate pages requires a record the next run can check before it acts, with five parts. First, the incident identity: a stable identifier that survives across systems, such as the incident ID, the service affected, and the error signature. Titles change; IDs and signatures let the next run recognise the same incident even when a monitoring tool creates a fresh alert for it.

Second, the current status, in plain terms: open, acknowledged, in progress, resolved, or cancelled. A status that only says "seen" is not enough, because seen is not resolved.

Third, what the fix was and how it was verified. "Restarted the worker" is a start. "Restarted the worker, error rate returned to baseline, and the health check passed three consecutive times" is a record the next run can trust.

Fourth, who resolved it and when. A resolution from three months ago should not suppress a page for the same error today. A resolution from three hours ago, for the same service and error signature, should.

Fifth, the reopen rule. A resolved incident should stay resolved until something specific happens: the same error signature reappears above a threshold, a health check fails again, or a customer reports the same symptom. That rule stops two opposite failures: paging on every tremor after a fix, and staying silent when the problem genuinely returns.

The pre-page check that prevents the duplicate

With that record in place, add one step before any page goes out: check memory, then check the live system, then decide.

The agent reads the resolution record for every incident on its list. If an incident was resolved recently, with a verified fix, and no reopen condition has been met, the run skips the page and leaves a note explaining why: which resolution it matched, when it happened, and what would reopen it. That note turns a skip into an auditable decision.

If the record is unclear, the agent checks the live system before paging: is the error still occurring, is the health check still failing, is the service still degraded? A page should go out when live evidence says the problem is real, not when a stale list says it might be. When the agent does page, it writes the page into the same record, so the next run knows a page already went out and what happened next.

One memory across the tools that touch an incident

Resolutions get lost because an incident touches many tools, and each keeps its own version of the truth. The alert lives in the monitoring tool, the fix in the ticket, the verification in a chat thread. An agent that reads only one of them misses the other two.

That is the gap a shared memory layer closes. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to run and nothing to install. A scheduled agent connects to it over MCP, and the same memory is available to every tool the team uses, not just the one that raised the alert. The 2 a.m. resolution, the verification that the service recovered, and the note about what would reopen the incident all live in one place, and every run reads from that place before it decides to page.

Because Vilix AI stores full conversation history, not just facts, the record keeps the reasoning too: why that fix was chosen, what was tried first and did not work, and what to check if the same error returns. The data is portable, so the team can export everything or delete it anytime. Vilix AI is free forever, with a 7-day Pro trial that needs no credit card.

Before the next on-call rotation

Before the next rotation starts, check four things. Does every incident on the agent's list have a stable identity, or does the agent match on titles that change? Does the agent read resolutions from the same place humans write them, or only from the monitoring tool? Does it distinguish acknowledged from resolved? And does it leave a note when it skips a page, so a skipped page never looks like a missed one?

A paging agent should wake a human when something is actually wrong. That only works if the agent remembers what is already fixed. Give it that memory, and the 6 a.m. page for a 2 a.m. resolution stops happening.

Learn more at Vilix AI.