Skip to main content

DataDog Webhooks Review

DataDog is a monitoring and security platform for cloud applications.

When we look at webhook solutions, we’re generally looking for 7 things: signature verification, retries, manual retries, exponential backoff, visibility/logs, event types, and multiple endpoint support.

TL;DR:
⬜ Signature Verification
✅ Retries
⬜ Exponential Backoff
⬜ Manual Retries
⬜ Visibility into Logs
⬜ Event Types
✅ Multiple Endpoints Support

Signature Verification

Signature Verification is a critical security feature of webhooks. It lets users verify that a webhook was actually sent from the expected source.

DataDog does not mention any signature verification capabilities (you'd generally see some mention of it in the header section). They do offer the ability to set custom headers and their authentication suggestion is to use basic HTTP authentication by modifying the endpoint URL.

While we support basic HTTP authentication at Svix, we highly recommend signing webhooks with encrypted signatures.

Retries ✅

Webhook messages often fail. Without retries, users may miss many notifications which results in a bad user experience.

The DataDog documentation states that failed webhooks will be retried 5 times in the case of an internal error or a 5xx response from the endpoint.

Looking to send webhooks at scale?

Exponential Backoff

Exponential backoff is an algorithm that increases the delay between retries exponentially. This ensures that your system won’t get bottleneck from having to re-queue failed webhooks while also giving users time to fix broken endpoints before they burn through all their retry attempts.

There is no mention of the delay between retries.

Manual Retries

In the event that a user’s endpoint is failing, its nice to give the developer tasked with debugging the endpoint, the option to initiate a retry manually instead of having to wait for the next scheduled retry (this could be several hours of waiting if they’re close to the end of the retry schedule).

There is no mention of triggering retries manually.

Visibility into Logs

Giving users visibility into the delivery logs is critical for troubleshooting/debugging.

There is no mention of logs or a UI for viewing the status of webhooks.

Event Types

Event types are identifiers denoting the type of message being sent and are the primary way for webhook consumers to configure what events they are interested in receiving.

DataDog does not offer event types but has many "variables" that enable users to create custom payloads. It's nice to have the flexibility to create any payload you want from the variables but it would also be nice to have some predefined event type payloads to start from.

Multiple Endpoint Support ✅

Many webhook solutions only allow one endpoint URL to be specified where all messages will be received. By enabling your users to create multiple endpoints, they’ll be able to choose which endpoints receive which messages. Multiple endpoint support and event types go hand in hand.

DataDog allows creating multiple endpoints through their API as well as through the Webhook Integration section of their web app.

Summary

There were a lot of features we like to see in webhook systems missing from DataDog's implementation. Their custom payload implementation using variables was unique and could be ideal for their use case as there are so many data point people may want to report on.

If you’re looking to implement world class webhooks, consider trying Svix, the enterprise ready webhooks service. Svix makes it super easy to build a secure, reliable, and scalable webhook solution via API.