> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Troubleshooting: quiet-hours blocks that fired during allowed hours
> Triage the false-positive quiet-hours block — the recipient reports an allowed-hour send that still returned next_allowed_at. Isolate which of the three false-block layers fired (campaign fallback window, org channel gate, TCPA voice rails), then route to the knob, the runbook, and the override filing path.
# Troubleshooting: quiet-hours blocks that fired during allowed hours
A recipient says "the send was fine — it went out at an allowed hour,"
yet your logs show `next_allowed_at` and a block. That's a false-positive
quiet-hours block: a gate that held a send while the recipient's local
time was technically legal but the wrong layer or a DST misread said
otherwise. This page works the triage — which of three false-block
layers fired, how each layer's responsible knob differs, and how to file
the override without weakening the one platform-owned gate. For the
three-layer model itself, see
[Federal vs state vs tenant voice gates](/concepts/federal-vs-state-vs-tenant-voice-gates);
this page works the failures, not the statutes.
The false-block triage below is a **tenant-owned** diagnostic — you
inspect the three layers, identify the false positive, and report it.
The TCPA federal voice window (invariant-class **#68**) is the one
gate you do **not** weaken even when it misfires: it has no tenant
override, no `skip` flag, and no `timezone_override` escape hatch.
If the federal rail is the culprit, the fix is **data repair or a
scheduled send against `next_allowed_at`** — never a "looser" setting.
For a genuinely wrong federal `next_allowed_at`, file it as a
platform defect, not a posture complaint.
## The three false-block layers
A quiet-hours block that reports `next_allowed_at` while the recipient
is in allowed hours came from **one of three layers**, and each layer
owns a different knob. Identifying the layer first halves the debugging
time — and decides whether you fix it yourself or escalate it.
| Layer | Responsible knob | Where to file the override |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Campaign fallback window** | Settings → Campaign limits → Default quiet hours (or `PUT /api/v1/campaigns/quiet-hours/settings`). A campaign row with its own explicit window never reads the fallback. | Self-serve: tighten or relax the fallback, or set the campaign row's own `quiet_hours_start`/`quiet_hours_end`. |
| **Org channel gate** | `settings → quiet_hours..enabled` (+ `start_hour`, `end_hour`, `allowed_days`). Default off per channel. | Self-serve: enable only the channels that need the gate, or widen only the hours/days you truly want. |
| **TCPA voice rails (federal only)** | The federal 8 AM–9 PM recipient-local window, and its fail-closed posture on unresolvable timezones. **No tenant toggle exists**. | Data fix or timed send: pass a `timezone_override` on the read-path preview when the area code resolves wrong, or schedule to `next_allowed_at`. A genuine defect in the federal rail is a platform bug — file it, never bypass it. |
A single send can cross more than one layer, but the layers compose
*most-restrictive-wins* — the first layer that blocks wins the log, and
the recipient reports "the send went out" while the platform held it
on the layer they didn't see. For the composition rule, see
[Federal vs state vs tenant voice gates](/concepts/federal-vs-state-vs-tenant-voice-gates).
## The DST and timezone-resolution traps
Off-peak sends that still trip `next_allowed_at` are almost always one
of these two traps. Both are read-path defects (the send path inherited
the wrong zone or the wrong hour), never send-path bypasses.
### DST crossover
Twice a year, US daylight-saving time flips the recipient-local clock.
A contact-CRM field stamped "Pacific" no longer means `UTC-8` in July —
the DST-aware evaluation resolves the IANA timezone against the
recipient's actual local time, but naive integer-hour shortcuts in your
own scheduling layer re-derive the wrong offset. The most common DST
false positive is a send that "was scheduled for 9 AM local" by your
own worker, which crossed the spring-forward boundary and reopened the
window an hour early or an hour late. Worked timelines and the correct
pre-launch procedure are in
[Quiet hours across DST](/guides/quiet-hours-dst-crossover) — the fix
is to hand the deferral to the platform's `next_allowed_at` rather
than recompute on your side.
### Recipient-local timezone resolution
The `next_allowed_at` value is computed against the recipient's
resolved local hour. When the area code resolves to the wrong zone (a
relocated number, a VOIP number that has kept its original area code,
a zone with two DST-adjacent aliases like Arizona's Phoenix) a send
scheduled for one local hour lands at the wrong one. Run the preview
against the same recipient before you re-diagnose:
```bash theme={null}
curl -G "https://api.orbit.devotel.io/api/v1/compliance/quiet-hours/preview" \
-H "X-API-Key: dv_live_sk_your_key_here" \
--data-urlencode "phone=+14805551234" \
--data-urlencode "channel=voice"
```
```json theme={null}
{
"data": {
"allowed_now": false,
"local_hour": 7,
"local_timezone": "America/Phoenix",
"window_start_local": "08:00",
"window_end_local": "21:00",
"reason": "outside_window",
"channel": "voice",
"next_allowed_at": "2026-09-27T15:00:00.000Z"
}
}
```
If the reported `local_timezone` mismatches the recipient's true zone,
the fix is to persist the correct zone on the contact (or pass the
read-path `&timezone_override=` at preview) — never to
relax your `unknown_timezone_policy`. When the timezone resolution
itself is broken (an unresolved NANP area code, or a US recipient whose
area code is not yet mapped), work
[Dialing-window blocked voice calls](/troubleshooting/tcpa-window-blocked-calls)
first — resolution failures are their own class with their own
fail-closed posture.
## When the federal rail is the culprit
The TCPA federal voice window is the sole platform-owned gate in the
stack — the only one with no tenant toggle, no `skip` flag, no
fail-open posture, and `47 U.S.C. § 227(b)(1)(B)` framing the penalty
as one the platform cannot let you waive. That carve-out exists to keep
you from accidentally widening the federal envelope with a misreading.
If a send was held by this rail while the recipient says "the hour was
fine," only two outcomes are possible:
* **The federal rail itself misfired** — a genuine DST or resolution
defect in the rail. **File it as a platform defect.** Include the
full error body, the campaign or run ID, and the preview response.
Never attempt a bypass, a `skipTcpa` flag, a `startHour`/`endHour`
knob on the federal window, or a fail-open on an unresolvable
timezone — those would reopen the exact class of incident the
carve-out closed.
* **The federal rail read your send path wrong** — a campaign pacer
that deferred the contact, and your own dispatcher pushed the send
straight to the gateway anyway. Work the sentinel trail on
[TCPA voice-guard sentinel breadcrumbs](/troubleshooting/voice-window-sentinel-breadcrumbs)
to confirm the pace-defer ran before the gateway threw; if your own
scheduler bypassed the pacer's deferral, fix the scheduler, not
the guard.
The federal rail's fail-closed posture on unresolvable timezones is
the same class of failure covered in the error-code page — the
resolution failure belongs to the recipient's zone data, not to the
guard. For the error matrix itself, see
[Troubleshooting: resolve dialing-window blocked calls](/troubleshooting/tcpa-window-blocked-calls).
## Where to file each false positive
Each failure mode routes to a specific knob, a runbook to inspect, and
a place to record the override. Work the table once per false-positive
report, then follow the link for the deep walkthrough.
| Failure mode | Responsible knob | Runbook to inspect | Where to file the override |
| ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Campaign fallback fired during allowed hours** | Campaign fallback window (org-level), or the campaign row's own `quiet_hours_start`/`quiet_hours_end`. | [Quiet hours configuration](/guides/quiet-hours-configuration) — the two-window model and the fallback resolution order. | Tighten the fallback on Settings → Campaign limits → Default quiet hours / `PUT /api/v1/campaigns/quiet-hours/settings`, or set the campaign row's explicit window. Self-serve; no escalation needed. |
| **Org channel gate fired when you expected it off** | The per-channel toggle `quiet_hours..enabled` (and its hours/days). | [Quiet hours configuration](/guides/quiet-hours-configuration) — the per-channel gate table and the unknown-timezone policy. | Disable the channel (you own it), or scope the hours/days. Self-serve. |
| **TCPA federal rail fired with a wrong `next_allowed_at`** | None (the federal rail is platform-only). | [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard) — the carve-out, the fail-closed posture, and the statute the guard cites. | **File as a platform defect** with the error body, the run ID, and the preview response. A genuine DST or resolution failure in the rail is a bug to report, not a posture to relax. Never escalate as a feature request. |
| **DST crossover reopened the window wrong** | Your own scheduler's deferral re-computation (integer-hour shortcuts) — hand the deferral to the platform. | [Quiet hours across DST](/guides/quiet-hours-dst-crossover) — worked timelines and the pre-launch preview procedure. | Persist the platform's `next_allowed_at` in your queue rather than re-deriving; the pre-launch preview is the check. Self-serve in your runbook. |
| **Recipient-local zone resolved wrong** | Contact data (the area code resolved the wrong IANA zone). | [Quiet hours across DST](/guides/quiet-hours-dst-crossover) — steps 1–4 of the pre-launch preview. | Fix the zone on the contact record; pass `&timezone_override=` on the read-path preview if you need it ad-hoc. Self-serve in your data, not your policy. |
When a false positive doesn't fit any row — the send genuinely was in
window, the timezone genuinely resolved right, and the deferral still
landed — escalate with the full error body, the campaign or run ID, and
the preview response for the same recipient. That's the signal the
carve-out closed: a platform-only defect the sentinel can't see, not a
setting you can change.
## See also
* [Federal vs state vs tenant voice gates](/concepts/federal-vs-state-vs-tenant-voice-gates)
— the three-layer model and the precedence rule; read this once before
working any false positive.
* [Troubleshooting: resolve dialing-window blocked
calls](/troubleshooting/tcpa-window-blocked-calls) — when the same
`next_allowed_at` reports on an ad-hoc 1:1 dial, work the error codes
here first; this page handles the campaign/bulk failure shapes only.
* [TCPA voice-guard sentinel
breadcrumbs](/troubleshooting/voice-window-sentinel-breadcrumbs) —
when you need to prove the federal rail actually ran (or didn't) on
the send path, the sentinel breadcrumb trace is the audit trail.
* [Quiet hours configuration](/guides/quiet-hours-configuration) — the
org gate, the campaign fallback window, and the unknown-timezone
policy: the two tenant-owned knobs end to end.
* [Quiet hours across DST](/guides/quiet-hours-dst-crossover) — the
crossover rules, the two non-DST US zones, and the pre-launch preview
procedure.
* [US state calling windows](/compliance/state-calling-windows) — the
seven-state overlay and why a state reason code layers **on top of**
the three false-block layers above.
* [Send gates](/compliance/send-gates) — the full send-time gate stack
the quiet-hours layers sit inside (DNC, RND, RMD, BAA, frequency).