Webhook reliability usually starts after the cloud already has the event.
The platform can queue it, retry failed deliveries, replay it later and protect the destination from a retry storm.
That is useful.
But an IoT event may have a long journey before it reaches that point.
And if it disappears earlier, none of the cloud reliability machinery can help.
The event the cloud never saw
Imagine a machine produces a fault event at a remote site.
The local application tries to send it directly to the cloud.
The connection is unavailable.
If the application does not persist that event, the cloud never receives it.
There is no failed webhook.
There is no dead-letter queue.
There is no delivery log.
There is nothing to replay.
From the cloud's point of view, the event never existed.
That is the reliability gap before the webhook.
Cloud reliability and edge reliability are different problems
Once an event reaches a cloud delivery platform, the relevant failures may include:
- a destination returning 503
- rate limiting with 429
- expired credentials
- an invalid payload
- destination downtime
- slow receivers
Before cloud ingestion, the failures look different:
- internet connection unavailable
- local process restart
- machine restart
- local storage pressure
- lost transfer acknowledgement
- backlog accumulated while offline
Trying to handle both boundaries with the same application code creates unnecessary coupling.
A producer running in a factory should not need to understand why an external SaaS endpoint returned 429.
A cloud delivery system cannot persist an event that never reached it.
The two layers have different jobs.
The local handoff matters first
For an important IoT event, the earliest useful reliability boundary is often local.
The application creates the event and hands it to something on the same machine or local environment.
If that component durably accepts the event, the application no longer has to make cloud availability part of the operation.
The path becomes:
Application → durable local handoff → cloud ingestion → destination
This does not eliminate failure.
It places responsibility at boundaries where failure can be handled properly.
Direct-to-cloud is sometimes fine
There is no reason to add an edge delivery layer to every IoT system.
A device that sends replaceable state over a reliable network may be perfectly served by direct cloud publishing.
If one update disappears and the next update replaces it, losing an event may have almost no cost.
A local spool, replay system and durable identities would add complexity without much benefit.
The reliability gap becomes important when the event itself matters.
An alarm happened once.
A batch completed once.
A machine changed state once.
If that event disappears before cloud ingestion, no later retry system can reconstruct it.
Monitoring has the same blind spot
This problem also affects observability.
Cloud dashboards can show every event they received and every delivery they attempted.
They cannot report an event that disappeared before ingestion.
A clean-looking cloud dashboard can therefore coexist with missing source events.
End-to-end reliability needs evidence from more than one boundary.
At the edge, you care whether the event was accepted locally and whether it transferred.
In the cloud, you care what happened after ingestion.
Those are complementary views.
[Queuey Edge](/edge/) and Queuey Cloud use separate boundaries
Queuey Edge provides the local durable handoff. When PublishAsync returns successfully, the event has been accepted locally and delivery responsibility has moved out of the application.
Queuey Cloud then handles the next delivery boundary towards the destination.
The architecture is straightforward:
Application → Queuey Edge → Queuey Cloud → Destination
The point is not to push every system through more infrastructure.
It is to avoid leaving an important event in a gap where neither the application nor the cloud can reliably account for it.
A good reliability design starts where the event starts, not where the webhook starts.