Why a text can arrive late

The reminder went out at 9:02 on Tuesday morning. The customer says it arrived at 11:40 on Wednesday night, which is why she missed the appointment and why she's cross. Your delivery report says "delivered" with a Wednesday timestamp. Everyone's telling the truth, and the explanation is in a 3GPP standard that describes exactly this behaviour.

A text message works like a letter. The network takes it in, holds it, and hands it over when the phone is there to receive it. Most of the time "when" is a second or two later. Sometimes it's a day and a half, and the standard, the sending platforms and Ofcom's coverage data between them explain every reason why.

Store and forward, in the standard's own words

The document that defines SMS is 3GPP TS 23.040, published by ETSI as TS 123 040. The current edition, version 18.0.0 from May 2024, opens with the sentence that matters: "The provision of SMS makes use of a Service Centre, which acts as a store and forward centre for short messages." The Service Centre, or SMSC, is the piece of the mobile network that receives a text from the sender, keeps it, and makes the delivery attempts. Your message goes into a queue with a clock on it before it goes anywhere near the handset.

The standard defines a sender's text as a "mobile originated" message carried "from an MS to a Service Centre", and what the customer gets as a "mobile terminated" message carried "from a Service Centre to an MS". For a business the first half is replaced by an aggregator or sending platform talking to the SMSC, which is why our guide on how business texts reach UK phones spends time on that hop, but the second half is identical for everyone. The SMSC tries to deliver. If it can't, it waits.

What happens when the phone is off

Clause 3.2.6 of the standard describes a mechanism called Messages-Waiting. It's "only used in case of previous unsuccessful delivery attempt(s)" and the two causes it names are "temporarily absent mobile or MS memory capacity exceeded". Absent means the network couldn't reach the phone: switched off, in flight mode, out of coverage, or with a flat battery. Memory capacity exceeded is a full inbox, which still happens on older handsets.

When a delivery attempt fails for either reason, the network sets a flag against the subscriber. The standard calls it the Mobile-Station-Not-Reachable-Flag, and it goes to TRUE "when an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber". Alongside the flag, the network keeps a list of which Service Centres have a message waiting for that phone.

Then the network waits for the phone to reappear. Clause 3.2.7, Alert-SC, is the part that makes late delivery possible at all. It is a service that informs the Service Centre that a phone "to which a delivery attempt has failed because the MS is not reachable or because the MS memory capacity was exceeded" is "now recognized by the PLMN" either "to have resumed operation (e.g. to have responded to a paging request)" or "to have memory newly available". On receiving the alert, "the SC may initiate the delivery attempt procedure for the queued messages destined for this MS".

That last "may" is deliberate. A note in the same clause says repeated attempts can be of two kinds: one triggered "because the SC has been informed that the MS is active and available to receive short messages", and "an autonomous repeated delivery attempt by the SC". Then: "The application of these two options is defined by the providers of the SC and the network." So how often an SMSC retries on its own, between alerts, is an operator decision the standard doesn't fix. Two networks can hold the same text for the same phone and try at different intervals.

The standard also keeps ordinary texts from hammering an absent phone. Clause 3.2.5 says "delivery of a non-priority message shall not be attempted if the MS has been identified as temporarily absent". A business text is a non-priority message. Once the flag is set, the SMSC doesn't keep knocking; it waits to be told the phone is back, or for its own retry timer.

Put those pieces together and the Wednesday night delivery makes sense. The customer's phone was off or out of signal on Tuesday morning. The first attempt failed, the flag went up, the message sat in the SMSC. On Wednesday night the phone registered on the network again (she walked back into coverage, or charged it), the network sent Alert-SC, the SMSC delivered, and the delivery receipt carried the time it happened.

How long the network will wait

A text in the queue doesn't wait forever. Every submitted message can carry a validity period, and the standard's clause 9.2.3.12 says it is "counted from when the SMS-SUBMIT is received by the SC". In its one-octet relative form the number is a code from 0 to 255, and the code means different things in four bands: codes 0 to 143 count in 5-minute steps up to 12 hours; 144 to 167 add 30-minute steps up to 24 hours; 168 to 196 count in days up to 30 days; and 197 to 255 count in weeks up to 63 weeks.

When the period runs out the SMSC gives up, and the standard has a specific status for it. In the list of status report values, under the heading "Permanent error, SC is not making any more transfer attempts", code 1000110 is "SM Validity Period Expired". The sender, if it asked for a status report, gets told the message died in the queue.

What value the sender sets is, again, a choice. GOV.UK Notify, the government's sending platform, is unusually clear about its own. Its delivery times page says: "Once a message has been sent, our text message provider will try to deliver it to the recipient for up to 72 hours." Its status page describes what you see while that's happening. The message shows as "Delivering" because "Notify has sent the message to the provider. The provider will try to deliver the message to the recipient for up to 72 hours." And it names the cause that most late texts share: the status "Phone not accepting messages right now" means "the provider could not deliver the message", which "can happen when the recipient's phone is off, has no signal, or their text message inbox is full". That's the standard's "temporarily absent" and "memory capacity exceeded", in plain English, on a government web page.

Three days is a sensible setting. Long enough that a phone left in a drawer over a weekend still gets the message on Monday; short enough that a reminder for Tuesday's appointment isn't delivered the following week. For a one-time code it's far too long, which is a point for later.

Out of coverage, not just switched off

"No signal" sounds like something that only happens in the Highlands. Ofcom's Connected Nations 2025 report, published on 19 November 2025 with operator data from July 2025, says otherwise once you look indoors.

Outdoors the picture is good. 4G coverage from at least one operator "now reaches 96% of the UK landmass", and outdoor 4G coverage of premises from all four operators is 99% UK-wide, 94% in rural areas. Indoors is where texts get stuck. The report's table 3.4 puts indoor 4G coverage across the operators at 94% to 97% of premises UK-wide, 97% to 99% in urban areas and 78% to 84% in rural ones. Ofcom adds a caveat that explains a lot of individual complaints: its indoor figures come from "applying an average building entry loss of 10dB across buildings", which "provides only a simplified view of indoor coverage and the real experience depends heavily on the types of building material and insulation in a specific building". A stone cottage or a basement gym is not an average building.

The England report makes the operator spread explicit. Indoor 4G coverage from at least one operator reaches 98% of rural premises in England, but only 57% of rural premises can get it from all four. So a customer in a village with the wrong network for that village has no indoor signal at home, and a text sent at 9am waits until they go out to the car.

One mitigation Ofcom notes is Wi-Fi calling, which it defines as "the ability to make and receive a call and text/SMS over a Wi-Fi network", offered by all four operators, "although not all mobile phones are configured to support this feature". A phone on home Wi-Fi with the feature on receives the text at once. The same phone with it off waits for the alert.

What the sender sees, and what it doesn't

The standard calls the receipt a status report. Clause 3.2.9 says the Service Centre can tell the sender that a message was "successfully delivered to the SME", or that it "was not able to forward the message", with a reason that is "of permanent or temporary nature". It also says, in a line worth remembering, that "the status report capabilities of the SMS are optional, i.e. the choice of whether to offer status report or not is left to the SC operator". UK business traffic does get them in practice, which is why a delivery report exists at all, but the standard never promised one.

Notify's wording for the end state is the one to copy into your own understanding: "Delivered" means "the message was successfully delivered", and "Notify will not tell you if a user has opened or read a message". A delivery receipt proves the handset acknowledged the message at that moment. It proves nothing about whether anyone looked. (The glossary entry on delivery receipts draws the line in more detail.)

The useful thing a report gives you for a late text is two timestamps: when the network accepted the message and when the handset acknowledged it. If they're 38 hours apart, the gap belongs to the phone, and you can say so to the customer with a straight face.

Writing texts that survive being late

Since some fraction of texts will arrive hours after they were sent, write every message so it's still correct when it does.

Put the date and time in the text, every time. "Crown Dental: your check-up is on Thu 19 Nov at 10:30. Reply C to confirm." is true whenever it lands. "Your appointment is in one hour" is wrong the moment it's delayed, and "today" is wrong after midnight. Relative times are how a late text turns into a complaint.

Send reminders the day before, in the afternoon, rather than first thing on the day. A phone that's off overnight comes back on in the morning, picks up the queued message and the customer still has time to act. A text sent at 7am on the day has a shorter window to be late in.

Treat a "phone not accepting messages" failure as information. If the network gave up after three days, the number may belong to a phone that's rarely on, or to a person who's abroad, or to nobody. Try once more on a different day, then move that contact to a channel that works for them.

Set a short validity period on anything time-limited, if your provider lets you. A one-time code that's valid for ten minutes should expire in the queue, not arrive two days later as a mystery message from your brand. The standard's shortest band counts in five-minute steps, so the option exists.

And when someone complains, check the timeline before you apologise for a fault you don't have. CaptiFi Connect records a timeline per text, from accepted through sent to delivered or failed, with each timestamp, and sends the same events to your own system by webhook. The 38-hour gap from the opening is in there: a Tuesday morning submission, a Wednesday night delivery, and nothing wrong in between.