External notifications should be modeled as durable, destination-specific work when business

External notifications should be modeled as durable, destination-specific work when business correctness depends on delivery. A request handler that commits state and then starts an unawaited promise can report success before delivery begins; without an attempt ledger, bounded timeout, retry, and success/failure evidence, a missing notification cannot be distinguished from provider acceptance followed by downstream loss. This applies to critical chat/webhook side effects; it does not mean every low-value notification needs a queue, and process health alone neither proves nor disproves request-scoped abandonment.

A second diagnostic rule: first verify that every expected event type is actually routed to the destination. Mixed reports such as “some alerts arrive” can combine unreliable delivery for implemented events with event types that have no route at all.