Asterisk GotoIfTime selects the wrong branch or destination

Freeze one call and the expected policy result

Record the affected number, timestamp and timezone, channel and linked IDs, Asterisk and FreePBX versions, context, extension and priority, exact loaded time expression, explicit or host-default zone, expected branch, selected branch, resolved target and final caller treatment. Redact customer identity and credentials.

Classify the first divergence as wrong upstream route, wrong clock, wrong timezone, timespec mismatch, unexpected test time, wrong primitive, omitted label and fall-through, missing target, nested-condition error, FreePBX override or later destination failure.

Prove the clock used by the affected channel

Compare the incident epoch with the host clock and operating-system timezone, then render that same epoch with STRFTIME() in the explicit timespec zone when one exists. Keep browser, phone, CDR and administrator workstation displays separate because each can format the same event in another zone.

Check whether an isolated test path set TESTTIME() on the channel. A test clock belongs to that channel, while a wrong host clock or zone can affect broader schedules. Do not move production time to recreate the failure.

Evaluate every timespec field and boundary

Read the exact time, weekday, month-day, month and optional timezone fields from the loaded priority. Compare the incident to each field instead of judging only the clock time. Inspect overnight periods, end points, named weekdays, date windows and month transitions at the instant before, at and after the boundary.

For FreePBX-generated logic, map the loaded expression back to the owning Time Group or calendar mode. Do not repair a generated line directly. Preserve multiple ranges and exclusions in their displayed order and compare them with the written business policy.

Confirm the primitive and executed priority

Distinguish GotoIfTime() selecting a true or false target, ExecIfTime() conditionally invoking an application and IFTIME() returning data. Capture the priority that actually ran and the resulting context, extension and priority or returned value. A matching condition does not establish that an invoked application succeeded.

If a selected label is omitted, Asterisk documents fall-through to the next instruction. If a target is invalid, inspect the corresponding Goto() failure path, including any i extension or hangup behavior, instead of rewriting the schedule.

Separate FreePBX override and nested destination state

When FreePBX owns the path, record scheduled match, temporary or permanent override, selected Time Group or calendar group, matched destination and unmatched destination. A reset removes the override and returns evaluation to the schedule; it does not force open or closed.

Walk nested conditions one decision at a time. Keep a holiday match, normal-hours match and emergency manual control distinct. The first correct branch is not proof that a later announcement, IVR, queue, ring group, voicemail or custom destination is correct.

Correct the earliest mismatch and exercise restoration

Correct only the demonstrated owner: upstream route, supported clock or timezone setting, custom timespec, FreePBX Time Group, explicit condition zone, override, generated target owner or downstream destination. Apply FreePBX-owned changes through FreePBX and preserve the prior state and rollback trigger.

Repeat an isolated boundary test and an authorized real-time call for both branches, then reset temporary test time and overrides and verify an unrelated route. Record selected branch and final outcome separately. No PBX, module, clock, timezone, dialplan, condition, override, destination or live call was inspected or tested for this diagnostic.

Do not substitute an epoch wait for a time predicate

The WaitUntil guide distinguishes an active-channel wait from GotoIfTime() branch selection and later destination behavior.