Skip to main content

​
Overview

Courier’s delivery pipeline automatically retries failed delivery attempts when temporary issues occur. This includes handling provider outages, network failures, rate limiting, and other transient errors through exponential backoff retry strategies.

​
How Resilience Works

​
Automatic Retry System

Courier monitors three key areas and automatically retries when issues occur:
  1. Message Delivery: Retrying notification sends when providers are unavailable
  2. Status Tracking: Checking delivery status when providers can’t respond immediately
  3. Webhook Delivery: Ensuring your application receives delivery updates

​
Retry Behavior

When temporary failures occur:
  • Message delivery: Attempts continue for up to 24 hours before marking as failed
  • Status tracking: Delivery status checks continue for up to 72 hours
  • Webhook delivery: Status update delivery to your endpoints retries for 24 hours
  • Automatic resumption: Normal processing resumes when provider services recover

​
Retry Strategies

​
Message Delivery Retries

When Retries Happen:
  • Provider network outages or timeouts
  • Rate limiting from email/SMS providers
  • Temporary server overload at providers
  • Transient Courier system issues
Retry Timeline:
  • First 10 attempts: Exponential backoff (5 seconds to 15 minutes)
  • Remaining attempts: 15-minute intervals
  • Maximum duration: 24 hours (up to 104 total attempts)
Smart Backoff: The exponential delay prevents overwhelming struggling providers while ensuring quick recovery when services restore.

​
Status Tracking Retries

Even when messages are sent successfully, Courier continues tracking delivery status (delivered, opened, clicked) for up to 72 hours. Retry Timeline:
  • First 10 attempts: Immediate retries
  • 11th attempt: 1-hour delay
  • 12th attempt: 2-hour delay
  • Remaining attempts: 3-hour intervals for up to 72 hours

​
Webhook Delivery Retries

Courier ensures your application receives delivery status updates by retrying webhook deliveries when your endpoints are temporarily unavailable. Retry Timeline:
  • Same as message delivery: 24-hour retry window
  • Exponential backoff: 5 seconds to 15-minute intervals
  • Handles common issues: Network errors, temporary server downtime, rate limits
Webhook Reliability: Configure multiple webhook endpoints in your workspace settings to ensure delivery status updates reach your application even during maintenance windows.

​
Monitoring & Troubleshooting

​
Behavior During Outages

When provider outages or network issues occur:
  • Message queuing: Failed sends are queued and retried automatically
  • Delivery resumption: Processing continues when providers become available
  • Status tracking: Delivery status checks resume with full history maintained
  • Webhook processing: Missed delivery events are sent when endpoints are reachable

​
Tracking Resilience in Action

Monitor retry behavior through:

​
Implementation Considerations

  • Asynchronous delivery: Notification delivery timing varies based on retry attempts
  • Webhook idempotency: Endpoints should handle duplicate delivery status events
  • Retry monitoring: Message logs show retry attempts and final delivery status
  • Endpoint redundancy: Multiple webhook URLs reduce delivery status update failures

Message Logs

Monitor delivery attempts and track retry behavior

Outbound Webhooks

Configure reliable delivery status updates for your application

Channel Priority

Set up intelligent fallback routing to complement automatic retries

Courier Status Page

Check real-time service health and planned maintenance