Implementation worksheet · 6 min read
A Channel Provider Failure Policy for Lifecycle Orchestration
Write a policy per message class, not per provider. For each class decide four things: the retry window (how long a message is still worth delivering), whether a fallback channel is permitted, whether the message may be dropped entirely, and who is told when it is. Time-critical security and transactional messages justify aggressive retry and sometimes a fallback channel; marketing messages should usually be dropped rather than delivered late, because a promotion arriving nine hours after the window it referred to is worse than silence. The rule that must not be broken: a fallback to another channel requires consent for that channel — SMS-ing someone because email failed is a consent violation, not a clever mitigation.
Channel provider outages are handled by whatever the queue does by default, which is usually retry with backoff until success or a generic expiry. That is right for a password reset and wrong for a newsletter, and the difference is never configured because the queue has no concept of message class.
Put it into practice
1. Classify messages by how quickly they stop being useful
Security and access messages: useful for minutes. Transactional confirmations: hours. Scheduled marketing: the window it was written for. Newsletters: the day. This single classification drives every other decision in the policy and takes an afternoon to write for an existing programme.
2. Set a retry window per class, then stop
Retrying a password reset for six hours is pointless — the user gave up and requested another one. Retrying a promotion into tomorrow delivers a message referring to an offer that has closed. A window with a hard stop is better than indefinite backoff for both.
3. Decide drop-versus-deliver-late per class explicitly
Dropping feels like failure and is often correct. A time-bound marketing message delivered after its window damages more than it earns. Write 'drop' where dropping is right, so the system does it deliberately rather than delivering something embarrassing.
4. Gate fallback channels on consent for that channel
This is the rule with legal weight. Consent is per channel. An email failing does not create permission to SMS. Where a fallback is genuinely appropriate — a critical security notice to a user who consented to SMS — it is permitted because of the consent, not because of the outage.
5. Make queue depth and age visible, and alert on age
Queue depth alone is misleading; a large queue draining fast is fine and a small queue with hours-old messages is not. Alert on the age of the oldest message per class, against that class's retry window.
6. Decide who is told, and write the customer-facing line in advance
For a prolonged outage affecting transactional messages, someone needs to tell customers that confirmations are delayed. Drafting that sentence during the incident produces either silence or an overclaim. One prepared line, adjusted on the day, is enough.
Policy by message class
Copy this structure into your review document and record your observed result for each row.
| Message class | Retry window | Fallback allowed | Drop if undelivered | Notify |
|---|---|---|---|---|
| Password reset / access | 15 min | only with consent for that channel | yes, user retries | on-call |
| Security alert | 1 hour | only with consent for that channel | no — escalate | on-call + owner |
| Payment failure notice | 4 hours | only with consent | no — escalate | owner |
| Order/booking confirmation | 4 hours | no | no — escalate | support |
| Trial expiry warning | until expiry | no | yes, log it | owner |
| Scheduled campaign | until window closes | no | yes | campaign owner |
| Newsletter | same day | no | yes | campaign owner |
| Re-engagement | drop immediately | no | yes | none |
A failure worth checking
The fallback that violated consent. The email provider is down, someone routes critical messages to SMS to keep service running, and a share of those recipients never consented to SMS. The outage is handled and a compliance problem is created — one that persists after the provider recovers, and that is far harder to remediate than a delayed email. Consent is per channel, and an outage does not change what someone agreed to.
Common questions
Should we run a second email provider for failover?
It is a real option and it is not free: a second sending domain reputation to maintain, a second set of templates to keep in step, and a switchover that must be tested rather than assumed. Worth it when transactional email is load-bearing for the product; over-engineering for a weekly newsletter.
Is dropping a message ever the right answer?
Frequently, for anything time-bound. A campaign that fails to send during its window has failed; delivering it late converts a silent miss into a visible mistake. Log the drop so the volume is known rather than invisible.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.