What webhook retry backoff schedule does Jira Cloud apply before permanent failure?

Answer to the Question

Jira Cloud does not publish a deterministic retry schedule. The only confirmed behavior is that failed deliveries are retried for a bounded window of up to 14 days. Within this window, intervals grow exponentially with jitter, but the exact timing, jitter bounds, and the specific number of attempts are undisclosed. A delivery is marked as permanently failed once the 14-day window elapses or an internal retry limit is reached.

Likely Behavior and Assumptions

While the exact schedule is proprietary, the following behaviors are typical for Atlassian Cloud webhooks:

• Retry Triggers: Any non-2xx HTTP response or a request timeout is treated as a failure.
• Back-off Logic: Exponential back-off with random jitter is used to prevent thundering herd problems. The first retry usually occurs within seconds, with intervals doubling thereafter.
• Failure Window: The 14-day limit is the absolute ceiling; retries will cease regardless of the response code after this period.

Impact on Integration Design

Because the schedule is undocumented, integrations cannot rely on deterministic timing. Design your system based on these constraints:

• Idempotency: Assume duplicates can arrive at any point within the 14-day window. Handlers must deduplicate requests using stable event identifiers.
• DLQ Sizing: Do not size Dead Letter Queues based on assumed intervals. Provision capacity to handle the maximum potential volume of retries over the full two-week span.
• Alerting: Avoid hard-coding alerts based on specific retry gaps. Instead, trigger alerts based on consecutive failures or a total absence of successful deliveries over a wide grace period (e.g., 12 hours).

Developer Instance vs. Production

There is no documented difference in the retry algorithm between developer and production tenants. However, local testing is often distorted by:

• Rate Limits: The 100 req/min limit on developer instances may delay or truncate attempts.
• Tunnel Expiry: Forge tunnel sessions (expiring after 2 hours) prevent the observation of multi-day retry sequences.

Local tests should be used to verify idempotency, not to reverse-engineer the production retry curve.

Verification Steps

1. Point a webhook at a controlled endpoint that returns 500 Internal Server Error.
2. Log the arrival timestamp and request headers for every attempt over several days.
3. Calculate the inter-arrival gaps to establish an empirical baseline for your specific tenant.

Missing Diagnostic Detail

To confirm if your local testing is valid, you should ask Atlassian support: "Do developer instances utilize the exact same retry back-off schedule and 14-day window as production tenants?"