> As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down Really? I thought this would be co

> As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down Really? I thought this would be covered under most SLAs. > It seems to me that people saying your service is also potentially unreliable are missing the point a bit. The reason I (and _I guess_ other people) are thinking of this is that I read not having to invest significant engineering resources into building a robust failure resistant system as one of the main, if not the main selling point and I don't see how that is possible if I have to build it for Diahook in the first place. I understand Diahook has a great SLA and promises to be up as much as possible but things will always go wrong and there are so many points of failure outside of Diahooks control. So as a service maintainer, I still need to invest the same amount of engineering in the component that calls the webhooks. SLA is a business thing, not a technical one. When I evaluate multiple services and compare their SLAs, I see the probability of one service causing less disruptions to my business than the other. I don't see that as a reason to not write fault tolerant code. Engineers cannot rely on a higher SLA as a reason to throw fault tolerance out of the window. That's my main issue with using a service like this. However, there can be other features that could still make me sign up. Not having to write fault tolerant code just isn't one and anyone buying into that is shooting themselves in the foot.