Delivery & Monitoring

When you publish an event, Zyphr creates a delivery record for each matching endpoint, queues it for delivery, and tracks the full lifecycle — from initial attempt through retries to final resolution.

Delivery Lifecycle

Published → Queued → Delivering → Delivered (success)
                         ↓
                      Failed → Retrying → Delivered
                         ↓
                      Exhausted (all retries failed) → DLQ

Delivery Statuses

Status	Description
pending	Created, waiting in the delivery queue
delivering	Currently being sent to the endpoint
delivered	Successfully delivered (2xx response)
failed	Last attempt failed, retries remaining
retrying	Scheduled for another attempt
exhausted	All retry attempts failed — moved to Dead Letter Queue

Viewing Deliveries

Via Dashboard

1. Navigate to your WaaS application and open the Deliveries tab
2. Filter by:
   • Tenant ID — See deliveries for a specific customer
   • Event Type — Filter by event type
   • Status — Show only failed, exhausted, etc.
3. Click a delivery to see full details including request/response data

Via API

# List deliveries for an application
curl https://api.zyphr.dev/v1/waas/applications/{app_id}/deliveries \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -G \
  -d "tenant_id=tenant_abc" \
  -d "status=failed" \
  -d "limit=20"

# Get a specific delivery with full request/response
curl https://api.zyphr.dev/v1/waas/applications/{app_id}/deliveries/{delivery_id} \
  -H "Authorization: Bearer YOUR_API_KEY"

Retry Behavior

Default Retry Policy

Failed deliveries are automatically retried with exponential backoff:

Attempt	Delay	Cumulative
1 (initial)	Immediate	—
2	1 minute	1 min
3	5 minutes	6 min
4	30 minutes	36 min
5	2 hours	2h 36m
6	12 hours	14h 36m
7	24 hours	38h 36m

After all retry attempts are exhausted, the delivery moves to exhausted status and is placed in the Dead Letter Queue (DLQ).

Custom Retry Policy

Configure per-endpoint retry behavior:

curl -X PATCH https://api.zyphr.dev/v1/waas/applications/{app_id}/endpoints/{endpoint_id} \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "retry_policy": {
      "max_attempts": 4,
      "intervals": [30, 300, 3600, 86400]
    }
  }'

Manual Retry

Retry a specific failed or exhausted delivery:

Via Dashboard

1. Open the Deliveries tab
2. Find the failed delivery
3. Click the Retry button

Via API

curl -X POST https://api.zyphr.dev/v1/waas/applications/{app_id}/deliveries/{delivery_id}/retry \
  -H "Authorization: Bearer YOUR_API_KEY"

Circuit Breaker

The circuit breaker protects both your infrastructure and your customers' servers from cascading failures.

How It Works

1. Closed (normal) — Deliveries flow normally
2. Open (tripped) — After 10 consecutive failures, the circuit opens. No deliveries are attempted.
3. Half-Open (recovery) — After a cooldown period, a single test delivery is sent
4. Closed (recovered) — If the test succeeds, normal delivery resumes

What Triggers It

• 10 consecutive delivery failures to the same endpoint
• Timeouts count as failures (30-second timeout)
• Only consecutive failures trip the circuit — a single success resets the counter

What Happens When It Trips

• The endpoint is automatically set to disabled
• Pending deliveries for that endpoint are paused
• A notification is sent (if alert hooks are configured)
• The endpoint can be manually re-enabled from the dashboard

Rate Limiting

Zyphr rate-limits deliveries per endpoint to prevent overwhelming your customers' servers:

• Default: 100 deliveries per second per endpoint
• Excess deliveries are queued, not dropped
• Rate limits apply to the delivery rate, not the publish rate

Dead Letter Queue (DLQ)

Deliveries that exhaust all retry attempts are moved to the DLQ. These deliveries:

• Remain visible in the delivery logs with status exhausted
• Can be manually retried from the dashboard or API
• Are retained according to your plan's log retention period

Delivery Deduplication

Zyphr prevents double-delivery using idempotency:

• Use the idempotency_key field when publishing events
• If the same key is published twice, only one set of deliveries is created
• Internal deduplication also prevents duplicate delivery records for the same event+endpoint pair

Monitoring Best Practices

Set Up Alert Hooks

Configure alert hooks to be notified when:

• An endpoint is auto-disabled by the circuit breaker
• Deliveries are exhausted (all retries failed)
• Usage approaches plan limits

Review Delivery Logs Regularly

• Check for patterns in failed deliveries (specific tenants, event types, or endpoints)
• Monitor delivery latency trends
• Track success rate by endpoint

Provide Delivery Visibility to Customers

Use the Embedded Portal to let your customers:

• View their own delivery logs
• Retry failed deliveries
• Diagnose integration issues without contacting your support team

Log Retention

Plan	Retention
Free	3 days
Starter	7 days
Pro	30 days
Scale	90 days
Enterprise	Custom

Plan Limits

Plan	Events/month
Free	1,000
Starter	25,000
Pro	250,000
Scale	2,500,000
Enterprise	Unlimited

Next Steps

• Event Types — Define what events your platform publishes
• Endpoints — Configure where events are delivered
• Embedded Portal — Let customers manage their own endpoints
• WaaS Overview — Full getting started guide