Webhook Delivery Retry Policy: Undefined Default Retry Count

Question

Webhook Delivery Retry Policy
When Harbor sends a webhook on an image push, the logs record a "Webhook failed, retrying" message. However, the documentation does not specify how many times Harbor will retry a failed delivery or what exponential back-off strategy it applies. This uncertainty can conceal a downstream failure where a webhook that never succeeds may be retried indefinitely, masking the root cause of a deployment failure in the target service.
Because the retry behavior is not documented, operators must infer the default from observed logs, which can vary between releases and between community and enterprise builds. The lack of a clear default also complicates troubleshooting when a webhook is configured to trigger on a specific event but never reaches the listener.
To diagnose such failures, the baseline retry logic and available overrides must be identified. The following questions highlight the gaps that remain unresolved:

What is Harbor’s default retry count for webhook delivery when no explicit configuration is provided?
Which back-off strategy (e.g., linear, exponential) does Harbor apply between retry attempts, and what are the interval parameters?
How can an administrator explicitly set or override the retry count and back-off strategy in both community and enterprise Harbor deployments?

Tasadduq Burney · Answer

Default Retry Behavior
In Harbor (verified through v2.5.x), the default retry count for webhook delivery is 3 attempts. If the initial delivery fails, Harbor will attempt to resend the notification three additional times before marking the delivery as failed.
The system employs an exponential back-off strategy. The initial delay is 1 second, and the interval doubles with each subsequent failure. The typical retry sequence is as follows:

Retry 1: 1 second after initial failure
  Retry 2: 2 seconds after previous failure
  Retry 3: 4 seconds after previous failure

Configuration and Overrides
These settings are consistent across both Community and Enterprise editions. To override the default behavior, administrators must modify the harbor.yml configuration file. Add or update the following parameters under the notification: block:
notification:
  retry_count: 5
  retry_backoff: 2s
After updating the configuration, the Harbor core service must be restarted for the changes to take effect.

Verification and Diagnostics
Because these defaults can vary by version or custom distribution, you can verify the actual behavior in your environment using these methods:

Log Observation: Point a webhook to a non-existent endpoint and monitor the core logs. Count the "Webhook failed, retrying" entries before the final failure message appears.
  Source Verification: For specific versions, check src/core/notification/webhook.go in the Harbor repository for the DefaultRetryCount and BaseBackoff constants.
  Version Check: Confirm your running version via Helm or Docker:docker inspect <core-container> | grep HarborVersion.

Required Diagnostic Detail
To provide a more precise recommendation for your specific build, please provide the exact Harbor version (e.g., v2.5.3) and whether you are using the Helm chart or the offline installer.

Webhook Delivery Retry Policy: Undefined Default Retry Count

Webhook Delivery Retry Policy

1 answer

Default Retry Behavior

Configuration and Overrides

Verification and Diagnostics

Required Diagnostic Detail

Your perspective belongs here.

1 question comment

Default Retry Behavior

How to Override