Quiet Hours: Why Your Automation Texts at 6 a.m.

An automation that texts a customer at 6 a.m. is not using the wrong timezone. It is usually reading the timezone off the area code, which records where a phone number was issued rather than where its owner lives, and it is checking that timezone at the moment the batch is queued rather than at the moment each message is delivered. Both mistakes are invisible in the run log, because queuing ten thousand messages is one successful step and the platform will happily drain that queue for the next three hours.

There is a third mistake underneath those two, and it is the one that makes the obvious fix wrong. You cannot simply stop using the area code, because two states have written into law that the area code is what puts you under their rules.

This describes what the cited statutes and vendor docs say as of August 2026. It is a build guide, not legal advice, and the window list belongs with your counsel.

"8 a.m. to 9 p.m." is a default, not the rule

The federal rule is specific, and the parenthetical is where the engineering lives. Under 47 CFR 64.1200(c)(1), no person or entity may initiate a telephone solicitation to a residential subscriber "before the hour of 8 a.m. or after 9 p.m. (local time at the called party's location)." Not your local time. Not your server's. Not your CRM account default.

That same federal section defines telephone solicitation to exclude calls made with prior express invitation or permission and calls to someone with an established business relationship, which is why an appointment reminder to an existing customer sits differently from a cold promotional blast. State law does not copy that structure.

Oklahoma's Telephone Solicitation Act of 2022, effective November 1, 2022, prohibits a commercial telephone solicitation phone call "before 8 a.m. or after 8 p.m. local time in the called person's time zone." Its definition of prior express written consent explicitly contemplates delivery "by telephone call, text message, or voicemail transmission," so texts are in scope. An aggrieved recipient can recover actual damages or $500, whichever is greater, trebled at the court's discretion for a willful or knowing violation.

Florida is the example that should end the habit of hardcoding one window. The Florida Telemarketing Act at 501.616 prohibits a commercial telephone solicitation call before 8 a.m. or after 8 p.m. in the called person's time zone. The Department of Agriculture and Consumer Services, writing about the Do Not Call regime under 501.059, states that calls and texts are permitted from 8 a.m. through 9 p.m. local time. Two Florida numbers, two Florida statutes, and which one applies turns on whether you fall inside a licensing regime with its own exemptions. That is a question for a lawyer. The engineering consequence is not ambiguous: the window is a per-jurisdiction data input you maintain and version, not a constant you type into a condition.

The area code lies about the clock and still picks the courthouse

Every messaging platform and every homegrown workflow I have opened does the same thing when it needs a timezone: it maps the first three digits after the country code. The area code is the only field guaranteed to be present, so it wins by default.

It is also wrong often enough to matter. An area code records where a number was assigned. Wireless numbers travel with their owner indefinitely and across state lines, so a 617 number belongs to a person in Denver as easily as one in Boston, and nothing in the number changes when they move. Landline porting is constrained to a rate center. A person changing address is not.

The standard advice at this point is to drop the area code and use the address on the record. That advice is half right, and the missing half is what gets you sued.

Oklahoma's statute includes this: "There is a rebuttable presumption that a commercial telephonic sales call made to any area code in this state is made to an Oklahoma resident or to a person in this state at the time of the call." Florida's 501.059 carries the same presumption for Florida area codes, and its definition of a telephonic sales call covers a "telephone call, text message, or voicemail transmission."

Read that next to the portability problem and the design falls out. The area code is unreliable for deciding what time it is, and it is load-bearing for deciding whose law you are presumed to be under. Two different questions, one field answering both. So you do not choose between the area code and the address. You compute both windows and send only inside the overlap.

A worked example

Take a contact with a 405 area code, Oklahoma, whose service address on file is in Los Angeles. Pick an ordinary date in the middle of daylight saving, September 15, 2026, when Central is UTC-5 and Pacific is UTC-7.

Constraint	Window	In UTC
Oklahoma, by area-code presumption	8:00 a.m. to 8:00 p.m. Central	13:00 to 01:00 next day
Federal, at the recipient's known location	8:00 a.m. to 9:00 p.m. Pacific	15:00 to 04:00 next day
Sendable overlap	8:00 a.m. to 6:00 p.m. Pacific	15:00 to 01:00 next day

Ten hours, not thirteen. Now look at what the two naive builds do with that same contact. Area-code-only sends at 8:00 a.m. Central, which is 6:00 a.m. in Los Angeles, waking the customer two hours before the federal window opens where they are standing. Address-only sends at 8:30 p.m. Pacific, which is 10:30 p.m. Central, two and a half hours past the cutoff of the state whose area code the message went to.

Both builds pass their own test. Only the intersection is defensible.

One more trap sits in the same arithmetic. Most of Arizona, all of Hawaii, and Puerto Rico do not observe daylight saving. If any part of your pipeline stores a fixed UTC offset instead of an IANA zone name like America/Phoenix, it is correct for roughly half the year. Our write-up on what daylight saving does to scheduled automations covers the four separate clocks that have to agree before a scheduled flow fires when you think it does.

Your guard checks the wrong moment

The second failure has nothing to do with geography. The window gets evaluated once, when the run starts, and the messages go out over the following hours.

Twilio's scaling guidance is blunt about the mechanics. A US long code runs at 1 message segment per second, a short code runs at 100, and Twilio queues your messages for 10 hours by default. Ten thousand messages on a single long code is 10,000 seconds, which is 2 hours and 46 minutes of drain. Kick that batch off at 7:00 p.m. and the last message lands around 9:46 p.m. Nothing errors. The ten-hour queue is perfectly willing to hold a message until 5 a.m. and then deliver it.

Three more ways delivery drifts past the check:

• Retries. A carrier-level failure at 8:55 p.m. that retries with backoff delivers at 9:07 p.m. The retry policy has no idea a legal boundary sits between those two attempts. Our guidance on when an automation should retry a failed step applies here with one addition: a retry that crosses a send window must be dropped or rescheduled, never just delayed.
• Scheduled sends. A message scheduled for 8:45 p.m. Eastern in a tool whose account timezone is UTC is really scheduled for 3:45 p.m. or 4:45 p.m. Eastern depending on the season, and the confirmation screen will not tell you.
• Throughput throttling. Carrier filtering and per-campaign caps slow the drain unpredictably, so last month's drain time is not tonight's. Counting in message segments rather than messages is the difference between a batch that finishes in three hours and one that finishes in nine.

The rule that fixes all four: the send-time check belongs at the last step before the provider API call, evaluated against the current clock, per recipient. Not at the top of the workflow. Not once for the batch.

What a correct send-time guard looks like

Five pieces, in the order they should run.

1. Resolve a zone, not an offset. Derive an IANA timezone from the recipient's service or billing address and store it on the contact record as its own field. When there is no address, fall back to the area code and set a flag saying the zone is inferred. That flag is what lets you tighten the window for unverified contacts instead of guessing silently.
2. Compute two windows and intersect them. One from the resolved zone against the rule for that location, one from the area code's state against that state's rule. Send only when both are open. When the intersection comes back empty for a contact, that is a data quality alert, not a send.
3. Clamp to the strictest window you hold. For contacts whose zone is inferred rather than known, use the tightest window in your table rather than the federal default. Losing an hour of send time is cheaper than $500 per message.
4. Evaluate immediately before the API call. Per message, against the clock at that instant. If a message aged out of its window while sitting in your own queue, requeue it for the next open window instead of sending it late.
5. Set the provider's validity period to the time left in the window. Almost nobody does this, and it closes the loop. Twilio holds a message for ten hours by default, so one you handed over at 8:40 p.m. can still be delivered at 6 a.m. after your guard did everything right. Set the validity period to the seconds remaining before the window closes and the provider fails the message rather than delivering it out of hours.

Store the resolved zone, both windows, and the actual delivery timestamp on the run record. When someone asks in eleven months what time a specific message reached a specific person, the delivery callback is the only artifact that answers it. The enqueue log does not.

Consent belongs in the same conversation but not in the same field. A recipient's opt-out state and a recipient's send window are two pieces of consent data that drift independently, and opt-outs that fail to sync across tools are the more common of the two failures.

The industry treats the location problem as genuinely unsolved. When the Ecommerce Innovation Alliance petitioned the FCC on March 3, 2025 for a declaratory ruling on quiet hours, one of the two forms of relief it sought was structural: that the FCC address the impracticality of applying a called-party-location standard to mobile devices without access to location data. As of August 31, 2026, the FCC has not ruled. Until it does, the intersection rule is the conservative build, and conservative is the right posture when exposure is priced per message.

Where to start this week

Open one outbound campaign and answer two questions with data rather than memory.

First, what field does your timezone actually come from. If the answer is the phone number, you have the problem described above, and you can size it in an hour by comparing area-code state against billing-address state across your contact list. Every mismatch is a contact whose send window you are computing wrong, and the count is usually higher than people expect.

Second, pull delivery timestamps rather than send timestamps for your last large batch and find the latest one. If your platform only reports that messages were accepted, wire up the status callback before you touch anything else, because right now you have no evidence about when your messages arrive.

If your outbound messaging runs through a workflow you built rather than a campaign tool that handles this for you, the guard has to live in the pipeline as a real step with real state, which is the kind of thing we build into customer acquisition systems. If you would rather have someone say which of the five pieces you are missing, send us the shape of your setup.