Glossary

Webhook

An HTTP request one system sends to another when something happens, so the receiver does not have to poll.

A webhook is an HTTP request a system sends to a URL you provide, at the moment something happens. It inverts polling: instead of your system asking every minute whether anything changed, the other system tells you once, immediately. In monitoring it is how alerts reach anything that does not have a built-in integration — a ticketing system, a chat bot, an internal automation.

Three properties separate a webhook you can build on from one you cannot. It should be SIGNED, so the receiver can verify the request came from the sender and not from anyone who learned the URL — typically an HMAC over the raw body with a shared secret, checked before the body is parsed. It should be RETRIED on failure with a backoff, because the receiver will be down sometimes and a delivery dropped on the first failure is a delivery lost. And each delivery should carry a stable identifier so the receiver can recognise a retry it has already handled, because at-least-once delivery means duplicates are normal rather than exceptional.

On the receiving side, the discipline is to acknowledge quickly and process afterwards. A receiver that does its work before responding will eventually be slow enough to be treated as failed, and will then be sent the same event again while it is still working on the first copy.

In Uptimely

Uptimely sends outbound webhooks signed to the Standard Webhooks specification, with a stable delivery identifier, a timestamp checked against a tolerance window, a bounded retry ladder, and a secret you can rotate with an overlap period. Deliveries and their outcomes are visible per endpoint.

Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.