--- title: "Scheduled actions stop retrying forever" description: "A scheduled action that keeps failing now stops after a set number of attempts and reports what went wrong, instead of retrying silently for days." canonical: "https://firstsales.io/changelog/scheduled-action-retry-ceiling/" --- 1. [Home](/) 2. [Changelog](/changelog/) 3. Scheduled actions stop retrying forever [All updates](/changelog/) ImprovementAugust 13, 20265 min read # Scheduled actions stop retrying forever A scheduled action that keeps failing now stops after a set number of attempts and reports what went wrong, instead of retrying silently for days. Background work that fails repeatedly now gives up after a fixed number of attempts and records what went wrong. It no longer retries indefinitely without telling anyone. ## What changed A lot happens in the background: research on a lead, a draft being written, a message going out at its scheduled time. When one of those fails, retrying is usually right, because most failures are temporary. The problem was that retrying had no end. A job that failed for a permanent reason retried on the same schedule as one that failed because a service was briefly down. It would keep going for days, failing identically each time, and nothing surfaced. Retries now have a ceiling. After a set number of attempts, the job stops and records the reason it stopped. That reason is visible rather than sitting in a log. The ceiling is set per kind of work, because the right number differs. Something that depends on an external service gets more attempts than something that failed because the input was wrong. ## Why it matters Endless retrying costs three things. It wastes the capacity that could be running work that would succeed. It hides the problem, because nothing ever reports a failure. And it delays the fix, because you find out when you notice a number that stopped moving. The second one is the real cost. A job that has failed forty times over three days is a problem someone should have known about on the first day. Stopping and reporting turns an invisible situation into a visible one. There is a smaller benefit in the queue itself. Jobs that will never succeed stop occupying attempts that other jobs could use, so everything else moves faster. ## How to use it Nothing to set up. Ceilings apply automatically. When a job stops, the reason appears on the thing it relates to. A lead whose research gave up shows that on the lead. A draft that could not be generated shows it on the draft. Read the reason before retrying. Some are worth another attempt because the underlying cause has since been fixed. Some will fail again exactly the same way, and retrying only wastes time. ## What causes a job to give up An external service that stays unavailable. Enrichment sources and mail providers go down, and usually come back within the retry window. When they do not, the job gives up and says the service could not be reached. A permanent input problem. A website that no longer exists, an address that cannot be delivered to. More attempts do not help. A repeated timeout. Some pages are slow enough that they never finish inside the allowed time. After several attempts, the job stops rather than spending capacity on the same page indefinitely. ## What happens next A job that stops does not restart on its own. This is deliberate. Automatic restarting is what produced the original problem. You can retry manually once the cause is dealt with. A lead whose research failed because a site was down can be retried when the site is back, and the retry starts with a fresh set of attempts. Where a lead is stuck on work that will not complete, the campaign moves on rather than holding the lead indefinitely. A lead whose research cannot finish still gets an email, written from what is known. ## Choosing the ceilings The numbers are set per kind of work, based on how failures actually distribute. Work that depends on external services gets more attempts, because those failures are usually temporary and usually clear within a few hours. Work that fails on its own input gets fewer, because those failures do not clear with time. Trying a malformed address ten times produces the same result as trying it twice. The aim is that a temporary failure survives the outage and a permanent one surfaces quickly. Set too low and real work gets abandoned during a brief blip. Set too high and the original problem comes back. ## Seeing what stopped A job that gave up records where it stopped and why, and that record sits on the object the work belonged to rather than in a system log nobody opens. A lead whose enrichment stopped after repeated timeouts carries that on the lead. A draft that could not be produced carries it on the draft. This matters because the useful question is almost never "what failed" in the abstract. It is "why has this particular lead not moved", and the answer needs to be where you are already looking when you ask it. The reasons are written to be read by a person rather than by an engineer. "The website did not respond after several attempts" tells you what to do next. A stack trace does not. ## Retrying deliberately Where the cause has been fixed, retry. A run of failures caused by an outage at an enrichment provider is worth retrying once the provider is back, and the retry gets a fresh set of attempts rather than resuming from an exhausted count. Where the cause has not been fixed, do not. A website that no longer exists will not exist on the second attempt either, and the credits and time spent confirming that are wasted. The reason text is usually enough to tell the two apart. When it is not, the useful test is whether anything has changed in the world since the job stopped. If nothing has, neither will the outcome. ## What this changed in practice The visible effect is fewer things sitting in an indeterminate state. Before, a piece of work was either done or somewhere between attempt four and attempt forty, and there was no way to tell which from the outside. Now everything is done, in progress, or stopped with a reason. Three states you can act on, rather than two states and a fog. ## Availability Live now on all plans, applied to background work across the product. No configuration required. [ PreviousSee when a campaign cannot move forward](/changelog/campaign-blocked-reasons-visible/)[Next A dead inbound mailbox no longer hides](/changelog/inbound-mailbox-health-visible/)