A retry policy for a failed scheduled skill refers to a set of rules that pre-classifies failure types and specifies the response for each, built from two mechanisms working together: a retry policy (whether to retry, how many times, how long between attempts) and a Fallback Instruction (what to do once retries are exhausted or a failure is judged unsuited to retrying at all). This differs from the general idea of 'failures should trigger a notification' — a plain notification only handles when a human finds out, not whether the system should try to fix things on its own first, and that's exactly the step most scheduled-task designs skip.
This is needed because a Scheduled Task differs fundamentally from a human doing the same work manually — when a person hits a transient error, they almost reflexively try again, barely thinking about it. A scheduled task has no one standing beside it; it can only react to any failure according to whatever logic was written in advance. If that logic is simply 'notify on failure,' the system treats a transient problem that would have resolved itself within fifteen minutes exactly the same as an event requiring immediate human attention. Over time this generates a pile of false alarms, and whoever is on call gradually becomes numb to notifications — so that when a genuinely structural problem finally occurs, the response is slowed down precisely because 'last time was also a false alarm.' The reason retry policy and Fallback Instruction exist is to encode that near-instinctive human reaction to transient error into a fixed rule a system can execute automatically.
In practice this involves three tasks. First, sort common error messages into transient and structural categories: timeouts, dropped connections, and 5xx server errors go under transient; authentication failures, 4xx request errors, and data validation failures go under structural — write this classification directly into the Scheduled Task's error-handling instructions. Second, set retry rules for transient failures, such as exponential backoff intervals (one minute, five minutes, fifteen minutes) and a maximum retry count, typically three, escalating to a human only after all three fail. Third, define the Fallback Instruction for structural failures and for cases where retries are exhausted — switch to a backup data source, produce a partial result flagged as incomplete, or simply stop and wait for a human — a choice that depends on whether the task can tolerate a partial result or requires full correctness to be usable at all. Put together, the entire failure-handling logic gets configured before the scheduled task ever fails for the first time, rather than being decided on the spot each time.
For you, this design turns whether the on-call person gets woken up at 3 a.m. from a moment's judgment into a pre-set rule, which directly affects how much your team trusts its own notifications — if alerts fire too often and turn out to be false alarms too frequently, people start skipping them, which is more dangerous than having no notifications at all, because the system looks like it's working while its warning signal has quietly stopped meaning anything. Setup cost is one-time, usually an hour or two to define the classification list and retry rules; ongoing maintenance is adding new error types to the classification list as they appear, keeping the rules aligned with reality. What genuinely deserves attention: don't design the Fallback Instruction as a silent failure, where the system simply stops once retries run out and nobody finds out. That's more dangerous than reckless retrying, because the problem just sits there undiscovered until someone eventually notices the task hasn't actually succeeded in days.
At 3 a.m., a scheduled month-end reconciliation task fails because the vendor's API timed out briefly. The system has two options: retry silently once, which usually succeeds the second time, or fire off a notification and wake up whoever is on call. Most teams designing scheduled tasks only think as far as 'notify on failure' and never work out whether to try saving it once before notifying at all — and that unresolved gap decides whether your team's phone actually rings at 3 a.m.
The first kind is transient failure: the vendor's server timed out, the network blipped, their API happened to be mid-maintenance — the defining trait here is that trying the same thing again a moment later usually just works, no different in essence from refreshing a page yourself. The second kind is structural failure: an expired credential, the vendor changed their API format, the input data was wrong to begin with — the defining trait here is that no number of retries changes the outcome, because the problem isn't bad luck this time, it's that something is genuinely broken.
Treating these two the same is where most scheduled-task designs go wrong. Staying silent and quietly retrying transient failures is reasonable. But applying that same 'just try again' logic to structural failures only means the system keeps knocking, uselessly, on a door that will never open — and by the time the one notification that actually matters arrives, the person who should be woken up has already learned to ignore 'retrying' messages, because too many earlier ones turned out to mean nothing.
This is exactly what a retry policy exists to solve: specifying, on failure, how many times to retry, how long to wait between attempts, and how that wait grows. A common pattern is exponential backoff — wait one minute, then five, then fifteen, and escalate to a human only after three failed attempts. The intent is to give transient problems enough room to resolve on their own (vendor maintenance windows rarely run past fifteen minutes) without waiting indefinitely, and without waking someone on the very first failure — most transient problems have already resolved themselves before the second retry even fires.
But a retry policy only answers 'how many times to retry.' It cannot answer 'should this failure be retried at all.' That's why it has to pair with a second mechanism.
A fallback instruction handles what happens after the retry policy is exhausted, or when a failure is identified as structural from the start — switch to a backup data source, produce a partial result flagged as incomplete, or simply stop and wait for a human. Without this, systems often just go silently idle once retries are exhausted, with nobody aware the task actually gave up. Together the two form complete failure handling: the retry policy decides whether to try again, the fallback instruction decides how to close things out when trying again stops working.
The key to telling the two apart is whether the error message itself can be classified. Timeouts, dropped connections, and 5xx-range server errors from the vendor are broadly transient. Authentication failures, 4xx-range request errors, and data validation failures are broadly structural. Writing that classification logic into the Scheduled Task's error-handling instructions lets Claude decide automatically, by error type, whether to retry or escalate immediately — rather than applying the same reaction to every kind of failure.
The cost of not having a retry policy comes in two forms. Either you wake someone at 3 a.m. for a transient problem that would have fixed itself in fifteen minutes, which over time trains people to ignore notifications on the assumption it'll resolve on its own — or you have no retry mechanism at all, and every transient blip gets reported as a full task failure, generating a pile of noise nobody actually needed to handle. What's actually worth spending on is the one-time work of designing the retry policy and fallback instruction, usually an hour or two. In exchange, every future failure gets judged by the same logic automatically instead of being triaged in the moment by whoever happens to be on call, with the bar for 'is this worth waking up for' shifting depending on who's awake. Where human attention should actually go is the structural problems that really are broken and won't fix themselves with retries — not toward re-confirming, every single time, whether this was just another network hiccup.