Webhook Latency Calculator

Quick Facts

Industry Standard

5-30 second timeout

Most webhook providers

Recommended Retries

3-5 attempts

With exponential backoff

P99 Target

< 10 seconds

For real-time integrations

Success Rate Goal

99.9%+

With proper retry strategy

Key Takeaways

Set connection timeouts between 1-3 seconds to fail fast on unreachable endpoints
Use exponential backoff (2x multiplier) to avoid overwhelming recovering services
Target P99 latency under 10 seconds for real-time webhook integrations
Include jitter (random delay) to prevent thundering herd problems
Always implement idempotency to safely handle duplicate deliveries

Understanding Webhook Latency

Component	Typical Latency	Notes
DNS resolution	1–50 ms	Cached: <1ms; uncached: 20–50ms typical
TLS handshake	10–100 ms	TLS 1.3: ~1 RTT; TLS 1.2: ~2 RTTs
TCP connection	1 RTT (~10–300 ms)	Depends on geographic distance
HTTP request/response	5–50 ms	Server processing time excluded
Webhook provider processing	0–100 ms	Time from event to outgoing request
Receiving server processing	1–500 ms	Your application's handler execution time
End-to-end (same region)	20–150 ms	Typical for well-configured webhooks
End-to-end (cross-continent)	100–500 ms	Geographic latency dominates
Note: Webhook latency is the sum of all components. Processing time in your server's handler is often the largest variable.

Status Code	Meaning	Webhook Implication
200 OK	Success	Delivery confirmed; provider stops retry
201 Created	Created	Also considered success by most providers
204 No Content	Success, no body	Widely accepted as success
400 Bad Request	Invalid payload	Provider may or may not retry (varies)
401 Unauthorized	Auth failed	Signature verification failed — investigate
404 Not Found	Endpoint not found	Provider will usually stop retrying
429 Too Many Requests	Rate limited	Provider should back off and retry later
500 Internal Server Error	Server error	Provider will retry (transient error implied)
503 Service Unavailable	Unavailable	Provider will retry with backoff
Timeout (no response)	No response in time limit	Treated as failure; provider retries
Note: Always return 2xx within a few seconds. For slow processing, acknowledge immediately and process asynchronously.

Provider	Initial Timeout	Retry Attempts	Retry Schedule	Max Retry Window
Stripe	30 seconds	Up to 80 retries	Exponential backoff	3 days
GitHub	10 seconds	3 retries	Immediate → 1 min → 10 min	~11 minutes
Twilio	15 seconds	3 retries	Increasing backoff	~1 hour
Shopify	5 seconds	19 retries	Exponential (5 min to 48 hr)	48 hours
SendGrid	10 seconds	None by default	No retry	Immediate only
Slack	3 seconds	~3 retries	Short backoff	A few minutes
Note: Return 2xx quickly to avoid retries. For long-running processing: return 200 immediately, process asynchronously. Duplicate webhooks are common — implement idempotency keys.

Webhook latency is the total time from when a webhook event is triggered to when the receiving endpoint successfully acknowledges the delivery. This includes network time, connection establishment, request processing, and response transmission.

Proper latency planning ensures your webhooks are delivered reliably without timing out, while avoiding unnecessary retries that could overwhelm your systems or exceed rate limits.

Components of Webhook Latency

DNS Resolution: 1-50ms typically (consider caching)
TCP Connection: 20-200ms depending on geographic distance
TLS Handshake: 50-200ms for HTTPS connections
Request Transmission: Depends on payload size and bandwidth
Server Processing: Varies based on endpoint implementation
Response Transmission: Usually minimal for acknowledgments

Total Latency = Connection Time + Request Time + Processing Time + Response Time

Retry Strategy Comparison

Exponential Backoff

The most recommended approach. Each retry waits exponentially longer: 1s, 2s, 4s, 8s, etc. This gives services time to recover and prevents overwhelming them with requests.

Linear Backoff

Delays increase by a fixed amount: 1s, 2s, 3s, 4s. Good for predictable recovery patterns but may be too aggressive for cascading failures.

Fixed Interval

Same delay between each retry. Simple but can cause thundering herd issues when multiple webhooks retry simultaneously.

Pro Tip: Add Jitter

Add random jitter (10-30% variance) to retry delays. This prevents synchronized retries across multiple webhook deliveries, which can overwhelm your endpoints when recovering from an outage.

Webhook Delivery Best Practices

Return 2xx immediately: Acknowledge receipt quickly, process asynchronously
Implement idempotency: Use delivery IDs to handle duplicate webhooks safely
Set reasonable timeouts: 5-30 seconds is standard for most providers
Use dead letter queues: Store failed webhooks for manual retry or analysis
Monitor delivery metrics: Track success rates, latency percentiles, and retry counts
Test with failures: Verify your retry logic handles various failure modes

Frequently Asked Questions

What's a good webhook timeout setting?

Most providers use 5-30 second timeouts. For real-time integrations, keep it under 10 seconds. For batch processing webhooks, longer timeouts (30-60s) may be acceptable. Always return a 2xx response quickly and process the webhook payload asynchronously.

How many retry attempts should I allow?

3-5 retries with exponential backoff is standard. This provides resilience against transient failures while avoiding infinite retry loops. After exhausting retries, move the webhook to a dead letter queue for manual investigation.

What HTTP status codes should trigger a retry?

Retry on: 408 (Timeout), 429 (Rate Limited), 500-599 (Server Errors). Don't retry on: 2xx (Success), 400-499 except 408/429 (Client Errors). For 429, respect the Retry-After header if provided.

How do I handle webhook security?

Use HMAC signatures to verify webhook authenticity. Check timestamps to prevent replay attacks (reject webhooks older than 5 minutes). Always use HTTPS. Consider IP allowlisting for additional security.

What is webhook idempotency and why does it matter?

Idempotency means processing the same webhook multiple times produces the same result. This is critical because retries may deliver duplicate webhooks. Use a unique delivery ID to deduplicate - store processed IDs and skip duplicates.

Can I use this on mobile?

Yes — the calculator is designed to work on any device. For complex multi-input calculations on small screens, landscape orientation gives more room to see all fields and results simultaneously.

Frequently Asked Questions

What is webhook latency and what causes it?

Webhook latency is the total time from when an event occurs on the sending system to when your application has processed the webhook notification. It's the sum of several components: 1. Event processing time (sender side): time from event occurrence to the provider queuing the webhook delivery. Most providers queue webhooks within milliseconds, but high-traffic periods can add seconds to minutes of queue latency. 2. Network latency: DNS resolution: 1–50ms (cached: under 1ms). TCP connection establishment: one round-trip time (RTT), typically 10–300ms depending on geographic distance. TLS handshake: 10–100ms for TLS 1.3 (which reduces to ~1 RTT from TLS 1.2's 2 RTTs). HTTP request transmission: depends on payload size and bandwidth. 3. Server processing time: your webhook handler's execution time. This is often the largest and most controllable component. Database queries, external API calls in the handler, and synchronous processing can add 100ms–5 seconds or more. 4. Acknowledgment transmission: time for your 200 OK response to return to the provider. Why low latency matters: providers have delivery timeouts (typically 3–30 seconds). If your handler doesn't respond in time: the delivery is marked as failed. The provider begins its retry sequence (which can duplicate work). The event appears "delayed" in your system. Best practice: acknowledge immediately (return 200 OK) and process asynchronously. This decouples webhook receipt from processing latency, making your system resilient to processing delays.

How do I handle webhook timeouts and retries?

Webhook timeouts and retries are a fundamental part of building reliable webhook consumers. Understanding the retry landscape: most providers retry failed deliveries with exponential backoff. A "failure" is triggered by: a non-2xx HTTP response. No response within the timeout window (typically 3–30 seconds). Connection refused (your server is down). Best practices for handling retries: 1. Respond immediately with 200 OK. Your handler should return 200 within 1–2 seconds, regardless of processing time. Move actual work to an async queue (Redis, SQS, RabbitMQ, background jobs). Never perform database-heavy or API-calling operations synchronously in the webhook handler. 2. Implement idempotency. Webhooks will be retried — you WILL receive duplicates. Use the webhook event ID (most providers include a unique ID) to deduplicate. Check if you've already processed this event ID before processing. Store processed event IDs in a database or cache with a TTL. 3. Handle partial failures gracefully. If processing fails after acknowledging: log the failure. Implement your own retry mechanism for the actual business logic. Don't rely on the provider's retry mechanism after you've acknowledged with 200. 4. Monitor delivery failures. Set up alerts for non-2xx webhook responses. Track retry depth — repeated retries indicate a persistent issue. Most providers offer webhook delivery logs in their dashboard. 5. Consider a dedicated webhook ingestion service. For high-volume webhooks: use a fast endpoint that only validates and queues. Process from queue separately. This provides back-pressure control and prevents your main application from being overwhelmed.

What is webhook signature verification and why is it important?

Webhook signature verification is the process of confirming that a webhook request actually came from the provider you expect, and that the payload hasn't been tampered with in transit. Why it matters: without verification, anyone who knows your webhook endpoint URL can send fake events — triggering order fulfillments, user account changes, or payment processing based on forged data. How it typically works: the provider generates a signature using: your webhook secret (known only to you and the provider). The request body (raw bytes). Usually a timestamp (to prevent replay attacks). Common methods: HMAC-SHA256: the most common approach. Provider: signature = HMAC-SHA256(webhook_secret, payload). You: recalculate the same signature and compare with constant-time comparison. Stripe example: Stripe-Signature header contains the timestamp (t=) and signature (v1=). Your validation: compute the signed payload as timestamp + "." + raw body, then HMAC it with your secret, then compare. GitHub example: X-Hub-Signature-256 contains sha256=<HMAC-SHA256>. Validate the raw request body against your secret. Implementation tips: always use the raw request body, not the parsed/re-serialized JSON (whitespace differences will break signature verification). Use constant-time comparison (hmac.compare_digest() in Python, crypto.timingSafeEqual() in Node.js) to prevent timing attacks. Reject requests where the timestamp is more than 5 minutes old (replay attack prevention). Store your webhook secret securely — treat it like a password. Never log the webhook secret or include it in error messages.

How do I debug webhook delivery problems?

Debugging webhook issues requires a systematic approach because the problem can be in the provider's delivery, the network, or your handler. Step 1 — Use the provider's delivery dashboard: most providers (Stripe, GitHub, Shopify, etc.) show recent webhook delivery attempts. Check: was the webhook sent? What HTTP status code did your server return? What was the response time? What was the payload? If the provider shows a 200 response but you didn't process it: the issue is in your handler logic, not delivery. Step 2 — Check your server logs: look for the incoming request to your webhook endpoint. Verify the endpoint path is correct (trailing slash matters in some frameworks). Check if middleware (authentication, rate limiting) is rejecting the request. Step 3 — Use a local testing tool: ngrok or similar tools expose your local development server to the internet. Use provider test events to send to your local endpoint. Tools like webhook.site or pipedream.com let you inspect raw incoming webhook payloads. Step 4 — Validate signature verification: add logging to see if signature validation is failing. Common causes: using parsed JSON instead of raw body. Incorrect secret. Whitespace or encoding differences in the payload. Step 5 — Check for timeout issues: if your handler takes >3–10 seconds, providers may time out before you respond. Add timing logs around slow operations. Refactor to async processing if needed. Step 6 — Test idempotency: replay webhook events from the provider's dashboard to test your deduplication logic. Ensure replaying the same event doesn't cause duplicate side effects. Tools for webhook development: ngrok (local tunnel), stripe listen (Stripe CLI), webhook.site (payload inspection), RequestBin (payload logging).

Quick Facts

Latency Analysis

Latency Breakdown

Retry Schedule

Key Takeaways

Understanding Webhook Latency

Components of Webhook Latency

Retry Strategy Comparison

Exponential Backoff

Linear Backoff

Fixed Interval

Pro Tip: Add Jitter

Webhook Delivery Best Practices

Frequently Asked Questions

Frequently Asked Questions