When calls do not arrive — endpoint health

The hardest failure to debug is the one that looks like nothing. If calls stop arriving, you cannot tell from your own logs whether nobody wanted your tool this week or whether every request has been failing for three days. So we show you.

Where to look#

Your Tools page lists every version you have published, and each one carries an Endpoint column. It has four states, and they are four different facts rather than four degrees of one.

State	What it means	What to do
Answering	The last call reached you and you delivered it. The timestamp is when.	Nothing.
Never called	No call has ever reached this version. That is not the same as working — nothing has tested it.	Check that the version is `PUBLISHED` and that your endpoint URL is right. Call it yourself first.
Failing	That many calls in a row did not deliver. The count resets to zero the moment one succeeds.	Fix the endpoint. Traffic is still being routed to you.
De-listed	After repeated failures we removed the version from the public catalog. It receives no calls at all.	Re-publish, once your endpoint answers. Submitting the same version with the same price, endpoint and documentation restores it; a changed price or endpoint ships as a new version.

Fixing your server is not enough on its own

Repairing the endpoint does not re-list the version, because we have no way to learn that you did — nothing is routed to a de-listed endpoint, so nothing can discover that it works again. You have to tell us, by publishing.

Submitting the same version again, with the same price, endpoint and documentation, restores it and resets its failure count to zero. That is not a loophole in immutability: nothing about the version changed, so only its status moves. If the fix changed your price or your endpoint, that is a new version instead.

The reset is deliberate and goes both ways. A restored version that kept its old run of failures would be de-listed again on the next sweep, which would look like the restore silently failing; and clearing the status without clearing the record would make the version permanently immune to de-listing — published again and never examined a second time, however often it failed.

What counts as a failure#

A call fails when the gateway cannot get your response to the developer. In practice that is one of:

a connection that could not be made, or TLS that did not complete;
no first byte within five seconds — the clock is on yourfirst byte, not on finishing, so a slow stream is fine and a slow start is not;
a response we refuse to relay: a redirect (we never follow one), a body over the size cap, or a shape that is not a response to the request.

A 4xx or 5xx you return deliberately also counts. From the gateway's side a refusal and a crash look the same, and both mean the developer got no answer.

What it costs you#

Once bytes have streamed, the charge stands even if your stream then breaks. The work was done and partly delivered, so the failure count will not move for that call.

What we do not tell you#

We record that a call failed, not why. The gateway knows whether it got no first byte, or a connection error, or an unrelayable response — and we keep only the fact of the failure and its time. We would rather say so than imply a diagnosis we do not have.

The count is also consecutive failures. It answers “is my endpoint broken right now”, and it deliberately does not answer “how many calls did I lose this month” — one success resets it to zero. If your endpoint is flapping, the count will look healthy between flaps; the last delivered timestamp is the more honest signal there.

A checklist when it says Failing#

Call your own endpoint from somewhere that is not your machine, over HTTPS, with a real certificate. A certificate your laptop trusts and nothing else is the most common cause.
Check the first byte. If you do work before writing anything, write a header or a keep-alive first. Five seconds of silence is a failure however fast the rest is.
Check the creator key version. If you rotated and deployed only the new key, calls signed for the previous version are refused by your own server — which we record as your failure, because from outside it is one. Seeverifying a request.
Check the registered host. Signature verification uses the host you registered, not the Host header that arrived. Behind a proxy those differ, and verifying against the inbound one works in testing and fails in production.
Compare against the reference endpoint. It is compiled and tested in our CI against the gateway's real signing code, so it is a known-good baseline rather than a sample. Seethe reference endpoint.