Reliability and self-healing

Reliability here is not about never failing — everything that touches the outside world fails sometimes. It is about failing safely and visibly: absorbing the blips that don’t matter, and making sure the ones that do end up somewhere you’ll see, with a diagnosis attached, rather than as a silent gap where an alert used to be. The worst outcome for an automation is not an error; it is dying quietly and you finding out weeks later that you stopped getting the thing you relied on.

A slow response, a brief network hiccup, a source that’s momentarily busy — these are not real failures, and they don’t reach you. Individual steps can retry a few times with a growing delay between attempts, and the delay is tuned to the kind of error: a rate-limit backs off more patiently than a transient network blip. A step can also be set to continue on error, recording what went wrong and carrying on with the rest of the run — useful when one optional source failing shouldn’t sink the whole thing. Errors handled this way don’t count toward the failure streak that triggers self-healing.

If an automation fails three runs in a row, it stops running and enters a healing state. This is where it stands apart from a simple scheduled script: rather than sitting broken until you happen to notice, it wakes the assistant to look at what went wrong — with the recipe, the recent failures, and a saved copy of what it last successfully saw all in hand — and work out a fix.

If a page has been taken down for good, or a source has changed in a way no recipe can follow, the automation doesn’t loop forever trying. It makes a bounded number of repair attempts within a day, and if none succeed it stops, posts a plain-language verdict of what happened, and notifies you. “This page no longer exists” is a more useful outcome than an automation that thrashes silently — and because it lands in your notifications, you find out and can decide what to do.

If an automation’s recipe uses one of your connected tools — your CRM, your email, a task tracker — and that connection isn’t in place yet, the automation is saved as a draft. A draft never runs and never fails; it simply waits, and the assistant tells you exactly what to connect. The moment you connect it, the draft arms itself and starts running on its trigger. The same guard applies to repairs: if a fix would need a tool you haven’t connected, the automation holds rather than acting without it.

Over months, some automations outlive their purpose: a watch on a project that wrapped, a digest for a job you left. Rather than let them accumulate, the platform gently retires ones that have clearly gone dormant — for example, an automation whose owner hasn’t been active in a long time, or one that has been failing far past the point of usefulness.