Troubleshoot and Retry Webhook Deliveries

On this page

Use Settings > Webhooks to follow a project change from its event payload to the receiver's response. You need the Administrator role. If you have not configured a receiver yet, start with Set Up Project Webhooks.

An event records a change in TestCollab. A delivery sends that event to one endpoint. An attempt is one HTTP request for that delivery. One event can have several deliveries when multiple endpoints subscribe to it.

Find an event and its deliveries

1. Open the Events tab, then Occurred events.
2. Filter by event type, Resource ID, or date and time range. Resource ID is the ID of the changed record. Combine it with an event type because different kinds of records can have the same numeric ID.
3. Select View payload for the event.
4. Read the saved payload, then use the drawer's Delivery logs table to inspect deliveries to each endpoint, including manual retries.

Select Details to open a delivery. The event drawer shows up to the latest 100 delivery records and indicates when more exist. Use the main Delivery logs tab for the paginated history. Reset clears filters; the refresh icon reloads the current view.

Events > Catalog > View example shows illustrative payloads for all supported event types. Viewing an example does not send a request. For a receiver test, use an endpoint's Actions > Send test menu.

Inspect a delivery

In Delivery logs, filter by event type, delivery status, Webhook ID, or creation date and time range. Webhook ID identifies the endpoint, rather than the event or the delivery. Select Details on a row.

The delivery drawer shows:

• The status, event ID, endpoint ID, attempt count, and next scheduled attempt when present.
• Each attempt's start time, duration, and signing secret version.
• The HTTP response status, or an error when no successful response was received.
• The request URL, headers, and body preview, followed by the response headers and body preview.

Pending results refresh automatically for a limited time. If the drawer says the delivery is still pending, select Refresh result. Logs retain at least 30 days of history. Previews redact sensitive fields and URL query values, and are limited to 16 KiB. A truncated preview is marked in the drawer. Use the original request at your receiver for signature verification; the log preview has been changed for display.

Understand delivery statuses

Status	Meaning
queued	The delivery is waiting to be sent.
in progress	An attempt is being processed.
delivered	The receiver returned an HTTP 2xx response.
retry scheduled	A temporary failure occurred and another attempt is scheduled.
failed	No more automatic attempts will be made. Inspect the error before retrying.
cancelled	Delivery was stopped, for example because the project or endpoint was disabled.

Delivered means HTTP success. If your receiver returns HTTP 200 with an error message in the response body, TestCollab still marks the delivery as delivered. Check the response and your receiver's own logs when its business action did not complete.

How automatic retries work

An endpoint allows between one and three total attempts, including the first send. Network, timeout, and TLS failures, HTTP 408, HTTP 429, and server errors (HTTP 5xx) can be retried within that limit. Other HTTP errors, such as 400, 401, or 404, require you to fix the receiver or its configuration first.

Automatic retries normally wait about one minute, then five minutes, with some variation. A receiver's Retry-After response can lengthen the delay, up to 24 hours. The drawer shows the next attempt time. webhook.test always has one attempt, regardless of the endpoint's configured limit.

Replay a failed delivery

1. Inspect the failed attempt and fix the receiver, URL, or signing secret configuration.
2. Ensure the project and endpoint are enabled and the project has a shared secret.
3. In Delivery logs, filter by failed and select Retry. You can also use Retry in an event's delivery table.
4. Review the new delivery result that opens.

Retry creates a new delivery of the original event payload. It keeps the same event ID and the old snapshot, even if the record has since changed. It uses the endpoint's current configuration and the current project signing secret. The original failed delivery stays in the history.

A failed delivery can create only one manual retry. If that new delivery also fails, inspect it and retry that newer failed row. Only failed deliveries can be retried; delivered, cancelled, and pending deliveries do not offer this action. Re-enabling an endpoint does not replay its old backlog automatically.

A timeout can happen after the receiver has already processed the request. Receivers must handle repeat event IDs safely so a retry cannot repeat a side effect. See Handling duplicate and out-of-order events.

Common problems

• No event appears: check the project switch and filters. Choose an event from the catalog and make an actual saved change. Saving unchanged values does not produce an update event, and changes made while project Webhooks are off are not backfilled.
• An event has no delivery: confirm that an enabled endpoint subscribed to that event when it occurred. A later subscription does not deliver earlier events. Refresh after allowing time for delivery processing.
• Send test is unavailable: enable the project and endpoint, and generate the shared secret.
• Signature checks fail: use the current project secret and the exact payload string from the signed envelope. After a reset, update every receiver.
• URL or connection errors: check public HTTPS access, DNS, the TLS certificate, and the configured timeout. Use a direct receiver URL; arbitrary redirects are not followed.