Express courier. Direct.
Also overnight.
x25pronto Switzerland takes goods direct to the destination. Small loads go by car. Larger loads go by van or Van XL. Direct, express and overnight trips run Monday to Sunday when a slot is free. Free times are shown in the booking calendar. This keeps the plan clear.
Webhook monitoring and incident handling for courier integrations
Concrete tools and workflows to detect failed webhook notifications, alert teams, buffer events in a DLQ and recover lost courier events safely.
Quick answer
Webhook monitoring catches failed notifications early. Combine alerts, a dead‑letter queue and an incident playbook to recover lost events and keep courier processes running across Swiss operations.
Immediate steps you can take
Instrument your webhook endpoints for metrics, enable alerts for HTTP error spikes and store failed payloads in a dead‑letter queue. Publish a short incident playbook with roles and recovery steps so the team can act fast when tracking updates fail.
Common failure causes in courier webhooks
Typical causes are transient network issues, server overload, schema mismatches and expired TLS certificates. Timezone and encoding differences can also break payload parsing between systems in Zurich, Geneva or Basel.
Recommended monitoring and observability stack
Use an API gateway for routing and rate limits, Prometheus + Grafana for metrics, ELK/OpenSearch or cloud logging for traces, and Sentry for exceptions. Track latency, error rate, retry counts and per‑endpoint success rate.
Alert rules and escalation flow
Create clear alerts: for example >5% 5xx in 10 minutes or repeated 4xx from the same client. Send alerts to Slack, PagerDuty or email and define SLA response times. Tie high‑severity alerts to the incident playbook for immediate action.
Dead‑letter queues and retry patterns
Persist undelivered events in a DLQ (Kafka, RabbitMQ, SQS). Implement exponential backoff with max retries and idempotency tokens to avoid duplicate deliveries. Provide an admin UI to inspect, filter and replay failed events.
Incident playbook: steps and communication
A concise playbook: 1) Detect: verify alert and set priority. 2) Contain: pause automatic retries if needed, secure the DLQ. 3) Diagnose: use logs and traces. 4) Recover: replay DLQ events or apply manual fixes. 5) Review: run a post‑mortem and plan fixes. Include customer notifications with affected tracking IDs and expected timelines.
Frequently asked questions
How do I know a webhook event was lost?
Match incoming events against order records and tracked IDs. A DLQ with audit logs shows which payloads failed delivery. Missing status transitions in an order timeline also indicate lost events.
When should I manually intervene in the DLQ?
Manually intervene when automatic retries fail, when high‑value consignments are affected or when a customer needs immediate correction. Use the admin UI to replay only selected events.
What retry strategy suits courier events?
Use exponential backoff with a limited number of retries (e.g. five) and idempotency keys. Courier events are time‑sensitive; avoid excessive retries that lead to stale notifications.
How should I notify customers in Switzerland?
Send concise messages in the customer’s language with affected order IDs, the root cause if known and next steps. Keep technical details minimal and focus on impact and resolution.