Summary
When Integrations sends an outbound web hook, it records the result of every delivery attempt in the web hook log. If a delivery does not succeed, you can review the failed entry and re-trigger it directly from the log so the notification reaches your external system. This article explains how to read the delivery statuses and how to resend or retry a failed web hook.
Introduction
Web hooks in Integrations push event notifications to an external endpoint the moment something happens, so downstream systems stay in sync without polling. Delivery is designed to be reliable: each request is HMAC signed and, if it fails, Integrations retries automatically with exponential back-off while the log preserves a record of every attempt.
Even so, an endpoint can stay unreachable long enough that automatic retries are exhausted, or it can reject a request while it is misconfigured. This feature is used by administrators and integration owners, the people responsible for keeping external systems connected. It lets them diagnose those failed deliveries and re-trigger them once the endpoint is healthy again, rather than losing the notification.
Key Concepts
- Web hook log: the record of outbound deliveries for your account, preserving every attempt so you can confirm receipt or diagnose a failure.
- Delivery status: the outcome recorded for a delivery. A delivery in progress or awaiting its attempt shows Pending, a delivery the endpoint accepted shows Success, and one that did not go through shows Failed.
- Last run status: the value that reflects the outcome of the most recent attempt for that delivery.
- Run count: the value that tracks how many times a delivery has been attempted, including automatic retries.
- Automatic retries with back-off: when a delivery fails, Integrations retries on its own with exponential back-off, so a briefly unavailable endpoint usually recovers without any manual action.
- Resend and retry: manual actions that re-trigger a delivery from the log, used when automatic retries have been exhausted or when you have fixed the endpoint and want to send the notification again immediately.
Steps to Follow
Opening the web hook log
Sign in as an administrator and open the Integrations area from your account settings. Go to the web hooks section and open the delivery log for the endpoint you want to inspect. The log lists recent deliveries together with their status and attempt history.
Identifying failed deliveries
Scan the log for entries whose status is Failed. The last run status tells you the outcome of the most recent attempt, and the run count tells you how many times that delivery has already been tried. A high run count with a Failed last run status indicates that the automatic retries with back-off have run and the endpoint still did not accept the request.
Diagnosing the cause before re-triggering
Before you re-trigger a delivery, confirm the endpoint is ready to receive it. Check that the endpoint URL is reachable over HTTPS, that the receiving service is running, and that it accepts and verifies the HMAC signature on the request. Resending to an endpoint that is still down will simply fail again and increase the run count, so it is worth resolving the underlying problem first.
Resending or retrying the web hook
Once the endpoint is healthy, re-trigger the failed delivery from its log entry using the resend or retry action. This sends the same notification again to the configured endpoint. The entry moves to Pending while the new attempt is in flight, the run count increases to reflect the added attempt, and the last run status updates to the outcome of that attempt.
Confirming the delivery succeeded
After re-triggering, refresh the log and check the entry again. A delivery that went through shows a Success status and an updated last run status. If it returns to Failed, the endpoint is still rejecting or missing the request, so revisit the endpoint configuration and signature verification before attempting another resend.
Conclusion
The web hook log gives you a clear, per-attempt view of every outbound delivery, so you can spot failures quickly using the delivery status, last run status, and run count. When automatic retries are not enough, fixing the endpoint and then resending or retrying the failed entry lets you recover the missed notification and keep your external systems in sync.