Monitoring Third-Party Webhook Delays with AWS Durable Functions
Source: Dev.to
Overview
In this blog I explain how we used Azure Durable Functions (actually AWS Step Functions equivalent) to monitor delays in receiving third‑party webhooks. When integrating with external services, webhook notifications don’t always arrive immediately—or sometimes not at all. We needed visibility into:
- Whether webhooks actually arrive
- How long they take to reach our system
Architecture
The solution consists of three main components:
-
API Gateway → Lambda – The Lambda makes a request to the third‑party service, starts a Durable Function by sending an event to EventBridge, and returns a synchronous response to the client.
-
Durable Function – Generates a
callbackId, stores the callback metadata in DynamoDB, and then waits until the callback is completed. This allows us to know if the webhook notification ever arrived and, if it did, how long it took.
-
API Gateway → SQS → Webhook Handler Lambda – The webhook handler consumes the notification from the third party, retrieves the associated
callbackId, and resumes the Durable Function execution. Using SQS prevents a race condition where a webhook arrives before the Durable Function has started.
Monitoring
All interactions are traced with AWS X‑Ray. You can also create CloudWatch Dashboards to visualize the average time it takes for a webhook to arrive.
Conclusion
By combining API Gateway, Lambda, EventBridge, DynamoDB, SQS, and Durable Functions, we gained reliable visibility into third‑party webhook delivery times and ensured that our system can handle delayed or missing notifications gracefully.
Thank you for reading.