What happens to your webhooks when the receiving service stays offline?
One of the infrastructure problems we’re working on with Adal sounds simple at first:
What happens when a webhook arrives, but the service that needs to process it is offline?
Most webhook integrations connect the provider directly to the receiving application:
Provider → Your application
This works until the receiver is deploying, restarting, behind an unstable network route, or unavailable for longer than the provider’s retry window.
At that point, the outcome depends entirely on the sender. Some providers retry for hours. Some make only a few attempts. Others give you a dashboard where you can trigger another delivery manually—but not all of them do.
The receiving application has very little control over this.
The approach we took
Adal puts a persistent receiving layer between the provider and the final destination:
Provider → Adal → Your application
Adal accepts and stores the webhook first. Delivery to the application happens separately.
If the destination is temporarily unavailable, Adal retries automatically. If all automatic attempts are exhausted, the user can restart the delivery manually after the service comes back online—as long as the webhook is still within its retention period.
There are two delivery options:
Direct HTTP for services with public HTTPS endpoints.
Adal CLI for local or private services without public IP addresses or open inbound ports.
The CLI establishes an outbound WebSocket connection, so a webhook can be delivered to an application running behind NAT, inside a private network, or even on a developer’s laptop.
The bigger lesson
The important part isn’t the retry algorithm itself. It’s separating two events that are often unnecessarily coupled:
receiving the webhook;
processing the webhook.
Once the request is stored independently, an outage becomes a recoverable delivery problem instead of an immediately lost event.
Of course, retries introduce another issue: duplicate delivery. A receiver may process a webhook successfully but fail to return a response before the request times out. Any retry system can then send the same event again.
That means the receiving application should still be idempotent and keep track of event IDs wherever possible. Reliable transport does not replace good webhook-handler design.
A question for other founders
I’m curious how other indie hackers handle this in their products:
Do you rely entirely on the webhook provider’s retry policy?
Have you built your own queue and redelivery interface?
Do your users ever need to receive webhooks inside private networks?
How long do you retain failed webhook deliveries?
I wrote a more detailed breakdown of the architecture, automatic retries, manual redelivery, and the differences between Direct HTTP and CLI-based delivery here:
Full article: https://adal.cloud/blog/2026-07-13-reliable-webhook-delivery-over-unstable-networks
I’d be especially interested in hearing about failure cases you’ve encountered in production.
