Our numbers, with the method shown.

From the check that noticed the change to our first delivery attempt. This is our own pipeline, with the source taken out.

Says nothing about how soon the change itself was noticed. That is the whole trip below.

Share of events accepted with a 2xx after retries, on endpoints that accepted at least one webhook that day. Every event type except test pings.

An endpoint that accepted nothing all day and a 4xx refusal are on the receiver's side and left out. A timeout on a working endpoint counts against us.

From the time on the newest entry of the flight's change history to our first delivery attempt. Flight changes only, over customer subscriptions.

Depends on how often a flight is being checked, which follows its phase. Entries more than a day old are skipped, because they did not cause the event.

Share of flight lookups not answered with a 5xx.

A 4xx is the API working as designed, including a flight that is not published yet.

Time our server took to answer flight lookups, from the request log. Answers with a 5xx are left out here and counted against successful lookups.

Measured on the server: your network adds to it. A lookup served from cache and one that goes to the source are in the same figure.

Better Stack checks the API from four regions every three minutes and confirms a failure before it counts. Complete days only.

Published after 14 monitored days. It shows whether the API answers, not whether every flight is current.