[alexbouchard]

We don’t have a public SLA right now but work with customers directly to establish one that makes sense for both.

That being said, check out this blog post https://hookdeck.com/blog-posts/hookdecks-approach-to-reliab... about our approach to reliability. Essentially we’ve decided to focus on ingestion by reducing the dependencies to a minimum and completely isolating it from the rest of our infra. We can’t guarantee 100% uptime, that would be unreasonable, but we can have a better likelyhood at ingesting your webhooks than you do.

[edoceo]

Our ingestion is a single binary running on $Provider.

Aren't you on $Provider too?

Wouldn't you be just as reliable as anyone else in $Provider? (But adding complexity)

I guess I don't see the problem.

[alexbouchard]

It boils down to the number of dependencies you have and the uptime of those dependencies. For instance, you'll need to write to some form of temporary or permanent storage like SQS, S3 or PG. What happens when this is down, or you've busted your connection limit? With webhooks, you have no control over the throughput, and enormous bursts of traffic are frequent.

You can build reliable ingestion, and we aren't reinventing the wheel on that front. The difference is that we've taken the time, and many teams prefer to invest that time elsewhere.

We can also take some extra steps (and will), such as having multiple $Provider as fail-over.

[EDIT]

To add to this, Hookdeck ingestion reliability is only part of the value proposition. What customers really appreciate is the visibility and error recovery. They don't have to build a robust asynchronous processing system. They can just deploy an HTTP endpoint and call it a day.

[codedestroyer]

thanks