How do you verify that OTP codes are actually delivered to real phones?

A delivery receipt comes from the same chain that carries the message: your SMS provider, one or more aggregators and the destination carrier. It tells you that a hop in that chain accepted the message. It does not tell you that a handset displayed it to the user who is waiting to log in.

Routing changes, filtering and sender-ID rewriting all happen downstream of the systems you can see. From the sending side, a lost code and a delivered code can look identical. The only place where the difference is visible is the last one: a real handset with a real SIM, reading its own message store.

A useful check records five things for every message. First, the outcome: received, or not observed inside the window. Second, the observed latency in milliseconds, from the moment you sent to the moment the phone held the message. Third, the sender exactly as the phone displayed it, whether an E.164 number or an alphanumeric sender ID.

Fourth, content integrity: whether the text arrived as expected, compared with the code itself masked so it is never stored in clear. Fifth, the context: timestamp, number country, carrier and access method of the receiving SIM. Without that context a latency figure cannot be interpreted, because it does not say which route it describes.

Latency is the time between your send and the arrival of the message on the phone. A single value is noisy; the useful signal is the pattern over days. Latency that keeps growing while every message still arrives often points to queueing or a route change upstream, well before users start to complain that codes expire.

Latency measured on one number and one SIM describes that route only. It is not a benchmark of a country's mobile network, and it should never be presented as one. Compare it with your own code expiry time and with your history, not with figures from other routes.

Silence means no message from an authorized sender arrived inside the window. The possible causes are several: your system did not send, the provider dropped the message, a carrier filtered it, or the sender changed and no longer matches the authorized list. The handset alone cannot tell these apart, so silence is the cue to check your own send logs for that timestamp.

Silence is only meaningful if the receiving phone was healthy. If the observer could not read the phone, the honest result is inconclusive, not silent, and it should not count against the sender. Witnio applies that rule server-side, and silence before the first successful observation does not open an incident.

Witnio never sends the OTP. You send it from your own system to the receiving number assigned to you. You declare the authorized senders (E.164 numbers or 3-11 character alphanumeric IDs, matched exactly, never a wildcard) and a correlation window between 60 and 3,600 seconds, 900 by default. An optional correlation token of 6-32 characters ties a specific message to the run that observes it.

Each observation becomes a run with its status, latency in milliseconds and evidence signed with Ed25519 over a canonical JSON form. Anyone can check the signature on the public verify page without an account. Evidence is kept 90 days on the Founder plan and 120 days on Standard. The corridor context is recorded in every signed record and shared on request.

System reliability was measured separately, with faults such as network loss and service restarts injected on purpose. That measurement describes whether the system completes and classifies runs on its own. It is not a delivery rate for any carrier.