Bitbucket Cloud webhook delivery and external endpoint: unclear retry back‑off intervals

Goal: Determine the exact exponential back‑off intervals Bitbucket Cloud uses when retrying a webhook delivery after a 5xx response, so that subscriber services can align their own retry or idempotency logic with Bitbucket’s behavior.

Constraint: The retry interval values are not exposed through the Bitbucket Cloud UI or REST API, and the delivery log only shows timestamps without indicating the delay applied between attempts. This lack of transparency makes it difficult to verify whether the intervals follow a fixed pattern (e.g., 1 s, 2 s, 4 s) or vary based on load, repository, or other factors.

Uncertainty: Without explicit documentation or observable configuration, it remains unclear whether the intervals are static, configurable per webhook, or dynamically adjusted, and whether the same pattern applies to all retry attempts across different environments.

Questions: What are the precise delay values (in seconds) applied between the first, second, and third retry attempts for a 5xx failure? Are these intervals constant for all webhooks, or can they differ per repository or account? Is there any mechanism—such as an API endpoint or header—to retrieve or influence the retry back‑off schedule?