#cbonser
1 messages · Page 1 of 1 (latest)
2/ No this is not configurable
1/ This varies between live & test mode + other conditions and is subject to us changing it, but in live mode the first retry should generally be much sooner than that.
Do you have a specific event ID I can look at?
Thanks for responding. Here is the event in question evt_3MlDtB2J1KLBnsI81FazvkiM
This was in 'live' mode. In live mode, what is the typical expected time to 1st retry?
Perhaps this one was longer because of the type of error Timed out connecting to remote host?
Looking into this still ⏳
Still digging, but this timing is expected if your endpoint were responding with a high error rate. That doesn't appear to be the case with your endpoint, so trying to understand why the first retry wasn't faster.
Ok, it does look like around the time of this particular event there were a number of connection timeouts lowering the overall success rate, enough that a slower retry policy ended up being applied to this event
Do I have visibility into that in our dashboard?
Sort of -- you can see the ~recent overall error rate on the summary here: https://dashboard.stripe.com/webhooks
Or the developer overview showing a summary across all endpoints but with a bit more granularity in time: https://dashboard.stripe.com/developers