> ## Documentation Index > Fetch the complete documentation index at: https://docs.usertick.com/llms.txt > Use this file to discover all available pages before exploring further. # Delivery and retries > Timeouts, the retry schedule, the delivery log, resending, pausing, and what turning off or deleting an endpoint does. ## Answer quickly A slow endpoint times out, and a timeout counts as a failed attempt. Usertick waits up to 30 seconds for a survey event delivery, and up to 10 seconds for an account notification, a test ping or a delivery sent with **Send again**. To stay within these limits, verify the signature, queue the work and answer with a 2xx before processing. ## Retries | Your endpoint answers | What happens | | - | - | | Any 2xx | Delivered. | | Nothing (a timeout, a network error or a host name that doesn't resolve), `408` or any `5xx` | Retried on the schedule below. | | `429` | Retried. A survey event delivery waits for the `Retry-After` header (60 seconds when it is missing, at most 1 hour per wait) without using up an attempt. An account notification is retried on the schedule below. | | `410` to an API or app subscription | The subscription ends and shows as **Ended**. Nothing more is sent to it. | | Any other status, including a redirect, `401` and `403` | Failed and not retried, because the same request would fail again. | Usertick retries 30 seconds, 2 minutes, 10 minutes, 1 hour and 6 hours after the previous attempt, with each delay varied by up to 20 percent. A delivery gets 6 attempts in all, over about 7 hours. Survey events and account notifications follow the same schedule. Test pings and deliveries sent with **Send again** are sent once. A retry carries the same `webhook-id`, a new `webhook-timestamp`, a new signature and the next `X-Usertick-Attempt` number. An account notification retry sends the same body. A survey event retry describes the response as it is at the time of the retry, so fields such as `status`, `assignees` and `updatedAt` can differ from the first attempt. When **Send again** delivers an account notification that is waiting for a retry, Usertick stops retrying it. Survey event retries are sent either way. ## Duplicates and order Delivery is at least once. In rare cases the same message arrives twice, and **Send again** repeats one on purpose. To handle both, store the `webhook-id` values you processed for a while and skip any you have already seen. Usertick doesn't guarantee order across deliveries. When order matters, use `createdAt` in the body. ## The delivery log Usertick keeps every attempt for 30 days, whatever sent it. When you select an endpoint's row under **Settings → Developers → Webhooks**, the row opens with its deliveries by hour over the last 24 hours and its **Deliveries**: the attempts from the last 7 days, newest first, in a list that loads more as you scroll to its end. A failed delivery offers **Send again**. Selecting a delivery opens the **Delivery log** on the right with that attempt open. The log lists all 30 days, newest first, also loading more as you scroll, says how many deliveries match its filters, and shows new attempts as they are sent. * **Status** (**Delivered** or **Failed**), **Source** (**Workflow**, **All surveys**, **API or app**, **Account notification** or **Test**) and **Survey** filter the list. * **Show details** opens one attempt with what went wrong, the message ID, the request body as sent (up to 64 KB) and your endpoint's response (up to 16 KB). * **Send again** sends the same body to the endpoint's current URL with the same `webhook-id`, a new timestamp and a new signature, and logs it as a new attempt. A body longer than 64 KB was not stored in full, so it can't be sent again. **Send test** in the row sends a [test ping](https://docs.usertick.com/developers/webhooks/events.md#test-pings). The API offers the same log for your own subscriptions: [list deliveries](https://docs.usertick.com/developers/api/reference/list-deliveries.md) and [resend a delivery](https://docs.usertick.com/developers/api/reference/resend-delivery.md). A subscription that ended can't receive a resend. On a published workflow's page, the line under its name shows how many runs it sent, how many failed and how many were skipped in the last 7 days. **Activity** lists its runs from the last 30 days, and a failed run offers **Retry**. ## When failures repeat A delivery counts as failed when its last attempt fails, or when the endpoint answers with a status that isn't retried. * **A workflow** pauses after 20 failed runs in a row. Members whose role has the **Manage workflows** permission receive "A workflow was paused", and the workflow shows as **Paused** on the **Workflows** page. After fixing the endpoint, select **Turn on** on the workflow's page. * **Survey events from Settings** pause after 20 failed deliveries in a row, and members whose role has the **Manage integrations** or **Manage developer settings** permission receive "A webhook stopped sending responses". After fixing the endpoint, select **Resume** in the endpoint's row or in its **Survey events** settings. * **An API or app subscription** pauses the same way and shows as **Paused** in the webhooks list. It resumes when the app that created it subscribes again. For Zapier, turning the Zap off and on does this. * **For any endpoint**, after 5 failed attempts in a row, members whose role has the **Manage integrations** or **Manage developer settings** permission receive an "A webhook is failing" notification that links to the endpoint. Test pings don't count. The notification is sent once per streak, and later failures in the same streak don't send it again. A subscription also ends, and shows as **Ended**, when the API key or app access that created it is revoked, or when the survey it is limited to is deleted. A subscription that ended because its survey was deleted stays ended, and members whose role has the **Manage integrations** or **Manage developer settings** permission receive a notification named after the app, such as "A Zapier trigger stopped", or "An API subscription stopped" for one an API key created. Subscribing to that survey again fails with `APK-006-005`, so turning a Zap off and on doesn't bring it back, and the Zap starts again only after its trigger names another survey. ### Events that arrive during a pause While failures keep a workflow, an endpoint's survey events or a subscription paused, Usertick keeps the events that would have been sent. It keeps each event for up to 7 days and at most 1,000 events for each workflow, survey events setting or subscription. When more arrive, Usertick drops the oldest first. After **Turn on**, **Resume** or a new subscribe, Usertick sends the kept events in the order they arrived, before any event that arrives afterward. Only a pause that failures caused keeps events. Nothing is kept for a workflow or an endpoint that is turned off, or for a workflow that is paused because its survey changed or was deleted or because [collection was paused](https://docs.usertick.com/workspace/organization.md#pause-collection) for the organization. When someone turns off a paused workflow or the endpoint of paused survey events, or when a paused subscription ends, Usertick drops the events kept for it. ## Turn an endpoint off To stop all sending without deleting the endpoint, select its row, select **Settings**, turn off **Active** and select **Save changes**. While the endpoint is off: * Workflow steps that send to it are skipped. A skip isn't a failure and never pauses a workflow. * Its survey events are not sent. * Account notifications and waiting retries are not sent. Events that occur while the endpoint is off are not sent later. After the endpoint is turned back on, sending resumes with the next event. Paused survey events stay paused until they are resumed. **Send again** still works while the endpoint is off. ## Delete an endpoint To delete an endpoint, select its row, select **Delete webhook** and type the endpoint's name to confirm. Deleting removes the endpoint with its delivery log and its survey events. If workflows still send to it, the dialog lists those workflows first, and **Delete anyway** deletes it. Their **Send to a webhook** steps stop sending until they point to another endpoint. The **Used in** section of the endpoint's **Settings** lists the workflows that send to it. ## Endpoint requirements * The URL must use `https://` with a valid certificate. Usertick checks the URL again before every send. * The host must resolve to a public address. Usertick doesn't send to private networks, loopback addresses or cloud metadata addresses. * Usertick doesn't follow redirects, so the URL must be the final one. * The endpoint should be idempotent, because retries, resends and the rare duplicate are expected. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.