Retries that learn: how Hookline schedules the next attempt

Most webhook systems retry on a fixed schedule: wait one second, then two, then four, then give up after a handful of attempts. That schedule is easy to reason about and wrong for almost every real endpoint.

Endpoints fail in patterns

A server that returns 502 during a deploy recovers in about ninety seconds. A rate-limited API tells you exactly when to come back. A dead endpoint never recovers and every attempt is wasted. Treating these three the same means you hammer the first, ignore the hint from the second and waste effort on the third.

What we do instead

Hookline keeps a small per-endpoint model: recent status codes, response latency and the last successful delivery. The scheduler reads a Retry-After header when present, stretches the backoff window for endpoints that flap, and opens a circuit breaker after a run of hard failures. When the breaker opens you get an alert instead of a thousand retries.

The result is fewer wasted attempts, faster recovery for healthy endpoints and a dashboard that tells you why an attempt was scheduled when it was.