What is a retry policy?

The first question is whether the failure is worth retrying at all. A timeout probably is. A rejection saying the data is malformed never will be.

Exponential backoff is the standard shape. Wait one second, then two, then four, so a struggling system gets room to recover.

Randomness matters more than it sounds. Without it, every client that failed at the same moment returns at the same moment.

There has to be an end. A policy with no limit is a client that will still be trying tomorrow, and somewhere a queue is filling up behind it.

Say your calendar service goes down for 90 seconds at 2:14 pm, just as a booking is being written to it. With no retry policy the write fails once and an error lands in a log nobody reads. Your customer turns up on Thursday for a slot that somebody else holds.

With a sensible policy, the sender tries again after 2 seconds, then waits 4, 8, 16, 32 and 64. Each wait has a random fraction of a second added, so a thousand other senders don't all come back together. Five retries fail. The sixth goes through 126 seconds after the first failure, and you never hear about it. Had the outage lasted an hour, the policy would stop after its last attempt and park the booking in a failed list for a person to handle. Engineers call that list a dead-letter queue.

Start with how many times a vendor retries, and over what total period. A policy that gives up after 30 seconds won't survive a routine five-minute outage. Next, ask what happens to the item after the last attempt, and whether it's kept somewhere visible or dropped. Does anyone get an alert when something lands in the failed list? Finally, are retried writes safe to repeat, or could you end up with two bookings?

Quiet failures are the expensive ones. A lost booking costs you the job plus the customer's opinion of you, and you won't know it happened until they're standing in your doorway.

Retry policy matters less for things you can recreate. When a summary email fails to send, you can shrug, because the record still exists wherever the call was taken. Anything that holds a promise to a customer, like a booked slot, deserves all four questions.

A call is answered regardless of whether a downstream system accepted the record, so a failing integration never becomes a failed phone call.

Records stay in GreetKeeper whether or not they reached your other tools, which is the practical protection against a lost booking.

Reliability of any specific connection depends on which one it is. The matrix states what is native and what goes through Zapier, because those behave differently under failure.