Retry logic
The policy governing how a workflow re-attempts a failed step, including how many times, how long to wait between attempts, and when to give up.
In more detail
Many failures in distributed systems are transient: a timeout, a brief outage, a momentary rate limit. Retry logic re-attempts the failed step rather than giving up immediately, which resolves a large share of these without any human involvement. The policy defines how many times to retry, how long to wait, and when to stop.
Naive retries can make things worse. Immediately hammering a struggling service can deepen an outage, and retrying a non-idempotent action can duplicate its effect. Sound retry logic uses backoff between attempts, caps the number of retries, and only retries operations that are safe to repeat, escalating the rest.
Where this shows up at Ceven
Ceven handles transient failures with retry rather than surfacing every blip as a hard failure, so a workflow rides out a momentary outage or rate limit on a connected tool. When retries are exhausted or the failure is not transient, the case escalates rather than silently failing, and the whole sequence is recorded in the audit trail.