Delivery health & logs

Delivery contract

Behaviour	Today
Timeout	10 seconds. Answer 2xx first, then process
Redirects	Public HTTP/HTTPS destinations are supported, up to 21 redirects. Every destination is validated
Automatic suspension	Disabled during the compatibility rollout. Failed deliveries remain visible in logs
Retries	match.*, fact.* and summary.*: up to 6 attempts with 30 seconds of retry delays. Other events: up to 3 attempts with 1 minute of retry delays
Ordering	match.*, fact.* and summary.* for one match are sent in order, one at a time. A retried delivery can arrive after a newer event. Across matches there is no guarantee
Delivery	At least once. A duplicate is normal, a lost event needs every attempt to fail
Idempotency	Use (entity, data.id, date) as the deduplication key

Redirects must remain on public HTTP/HTTPS destinations. Private-network destinations are rejected. Use 307 or 308 to preserve the POST method and body. Cross-host redirects do not retain Basic Auth credentials.

Retries

LIGR retries a delivery when your endpoint sends no answer, or answers 408, 429 or any 5xx. LIGR does not retry a 2xx, or any other 4xx. A 4xx means the request itself is wrong for your endpoint, and a repeat carries the same bytes.

The schedule depends on the event. match.*, fact.* and summary.* events are delivered in order per match, one at a time, so a failing endpoint must not hold a match for long. Other events, team.* and competition.*, have no order to keep and wait longer.

Attempt	Match events: wait before it	Other events: wait before it
1	None	None
2	None	15 seconds
3	2 seconds	45 seconds
4	4 seconds	—
5	8 seconds	—
6	16 seconds	—

The waits add up to 30 seconds for a match event and 1 minute for any other event. Each attempt also waits up to 10 seconds for your answer. An event that fails every attempt is lost. Retries cover a restart or a deploy on your side, not an outage. After a longer outage, read the entities you track once from the REST API and continue from the webhooks.

Five rules follow from retries.

• Delivery is at least once. A retry after a lost answer, or a worker that restarts mid-delivery, sends an event you already processed. Answer 2xx and skip it.
• A retry is the same event. date is the same on every attempt of one event, so (entity, data.id, date) still deduplicates it.
• A retry carries the entity as it is at that moment. The payload is read again for every attempt. Treat every delivery as the latest state of the entity, not as a diff.
• A retry can arrive out of order. A retry goes to the back of the match’s queue, so events for the same match keep flowing while it waits. Compare date, or updatedAt on the entity, and ignore an older delivery.
• One event counts once towards health. Each attempt is one row in the log. Only the final failed attempt of an event adds one consecutive failure. One lost event cannot move an endpoint to failing on its own.

Logs

The dashboard keeps the newest 50 attempts per webhook. Open Developers → Webhooks, open the webhook, and select Event Logs. Each row is one attempt. It shows the status, the response body, the payload and the recorded health.

Status in the log	Meaning
200–299	Your endpoint accepted the delivery
300–599	The request ended without a successful 2xx response
0	Your endpoint sent no response. It timed out, refused the connection or failed DNS
-500	LIGR failed before it sent the request

Health states

LIGR records the result of every delivery and shows one health state per webhook. A broken endpoint remains visible as degraded or failing; failures do not automatically suspend delivery during this rollout. LIGR will email affected customers with an effective date before enabling stricter delivery enforcement.

State	Meaning	What to do
unknown	No delivery attempted yet	Change something in a subscribed competition
healthy	The last delivery succeeded	Nothing
degraded	1 to 4 consecutive failures, or the last result was a failure	Read your endpoint logs. Deliveries continue
failing	5 or more consecutive failures	Investigate the failures. Deliveries continue
suspended	Delivery was already suspended	Fix the endpoint, then select Re-enable in the dashboard. LIGR keeps the history

Note

Changing the webhook URL resets its health to unknown. LIGR drops the deliveries queued for the old URL, so a new endpoint never inherits old failures. There is no API to re-enable a webhook. It is a dashboard action.

Keep your endpoint healthy

1. Answer 2xx in under 10 seconds. Queue the work.
2. Return 2xx for an event you already processed. A duplicate is not an error.
3. Alert on your own 5xx rate. LIGR does not alert you.