HookieIs Hookie working?
The check below asks Hookie's API, from your browser, whether it answers and can reach its database. That is all it measures: Hookie does not yet run an external uptime monitor. Below it, how to check your own endpoints and deliveries, what happens to your events while something is wrong, and where to look for a platform incident.
Checking…
Check it yourself
Is ingest taking events?
Send one to an endpoint and read the answer: a 201 means it is stored. In the console, an endpoint's activity shows what it received and what it refused over the last 7 days, and the project's Errors tab lists events that were kept but filtered out or not yet routed.
Are deliveries going out?
A project's Deliveries tab shows each destination's success rate, latency and failed attempts over a window you pick, and every delivery with its status, the response your endpoint returned and how many attempts it took. A destination that keeps failing is flagged on the destination and on Home.
Is the console up?
Sign in at app.hookie.ai. Signing in runs through WorkOS, so if the sign-in step fails while the rest of the console loads, check WorkOS's status below.
Is it the receiving end?
Open a failed delivery to see the status code, the response body and the timing your endpoint gave. A 4xx is your endpoint refusing the request; a 5xx, a timeout or a refused connection is it failing to answer.
What ingest's answer means
Every endpoint answers straight away, so the response your sender gets is the first thing to read.
| Response | What it means |
|---|---|
201 | Stored. The event is written, and handed on to rules, deliveries and workflows — by a background sweep if the first hand-off fails. |
201 with filtered: true | Stored, but the endpoint's own criteria rejected it, so it is not handed on to rules, deliveries or workflows. It is listed on the project's Errors tab. |
200 with idempotent: true | Already received. This is a retry of an event Hookie has stored, recognised by its Idempotency-Key header or the delivery id a known provider keeps across its retries (deduplicated_by says which), and it is not stored twice. |
4xx | Refused for a reason in the response body: a wrong URL (404), a bad or missing signature (401), a body that is too large (413), a suspended workspace (403). Nothing is stored. |
429 | Rate-limited or over the monthly event limit. The Retry-After header says when to try again. |
503 | The endpoint is switched off in the console. Nothing is stored, and providers that retry will retry. |
No answer, or a 5xx | Hookie could not take the event. Retry it, as most providers do on their own, and check the platform status pages below. |
What happens to your events while something is down
A 201 is not lost
Hookie answers 201 only once the event, and the record that it still has to be handed on, are written together. If routing or delivery fails after that, a scheduled sweep picks the event up again.
Deliveries retry for about a day
A 5xx, a timeout, a refused connection, or a 404, 408, 409, 425 or 429 from your endpoint is retried with backoff — eight attempts over about 27 hours — and then marked dead. Any other 4xx (a 401 after a rotated secret, say) is your endpoint rejecting the request itself, so it is marked dead at once and not retried. Either way, Replay one, or every failure in a time window, once your endpoint is fixed.
A failing destination is paused, not drained
After 10 dead deliveries in a row, over at least an hour, Hookie switches the destination off and holds its new deliveries instead of sending them to fail. Re-enabling it sends what was held.
Until Hookie answers, the sender keeps the event
If Hookie cannot be reached, nothing was stored and your sender still has the event. Send an Idempotency-Key with your own events and a retry of one Hookie already has comes back as a 200, not a second copy; the providers Hookie recognises are deduplicated on their delivery id. Stripe, GitHub, Shopify and most providers retry on their own; your own code should retry on a 5xx or no answer.
Platform status
Hookie runs on these providers, and each publishes its own incidents.
Cloudflare status
Runs all of Hookie: the Workers that take events and serve the console, its D1 database, Durable Objects, Queues and Workers AI.
WorkOS status
Signs people in to the console and authorizes connected coding agents. Ingest and delivery do not depend on it.
Stripe status
Takes subscription payments. Nothing else depends on it.
Getting notified
Hookie has no incident mailing list or feed yet. What it can tell you about your own workspace today:
- A destination's alert URL. When Hookie switches off a failing destination, it sends a signed POST to the alert URL set on that destination, so your own alerting hears about it.
- Broadcast Logs. Forward a project's logs and traces to your observability vendor over OpenTelemetry and alert on failures there.
- The changelog. Every change that reaches production, by the day it shipped.
If something looks wrong on Hookie's side, write to [email protected] with your workspace, the endpoint or destination, and the time it happened.