FreePBX time condition routes to the wrong destination

Prove that this call reached the expected time condition

Start with one affected call's timestamp, called number, caller identity and final destination. Confirm that the call reached the PBX, matched the intended inbound route and then entered the intended Time Condition. Sangoma's inbound-route guide describes a common route-to-time-condition pattern, but an installation can have DID and CID matches, nested conditions, IVRs, queues or custom destinations. A wrong route before the condition cannot be repaired by changing its hours.

Retain the FreePBX route and destination names, the actual call trace and the module versions. Keep the caller's display time separate from the server timestamp used to evaluate the dialplan.

Compare wall clock, timezone and time source

Record the PBX's current date, time, timezone and synchronization state at the incident. Sangoma documents setting the system timezone in System Admin and notes that correct time and timezone are fundamental to logs, error reports and CDRs. A phone, browser or UCP display can use another timezone and does not establish what Asterisk evaluated.

If the server clock or timezone is wrong, correct the supported system owner during an approved window and follow its stated restart requirement. Do not compensate by shifting every Time Group; that hides the clock defect and breaks the next seasonal transition. Preserve before-and-after values and compare a new call trace.

Evaluate the exact time group and timezone

A FreePBX Time Group supplies the matching ranges; the Time Condition selects the true or false destination. Inspect every linked range for time of day, weekday, month day and month, plus any explicit timezone supported by the installed module. At a boundary, write down the instant just before, at and after the transition. Overnight hours, end-point inclusivity and overlapping ranges must be evaluated from the generated condition actually loaded by Asterisk.

Asterisk's GotoIfTime syntax includes time, weekday, month-day, month and an optional timezone. If the generated dialplan contains an explicit zone, do not assume the host default is controlling that condition. Do not edit generated dialplan; return to the FreePBX Time Group or Time Condition that owns it.

Check overrides, holidays and nested conditions separately

A manual time-condition override can deliberately force one branch, and Sangoma documents override controls and holiday exclusions as separate configuration steps. Record the condition's scheduled state, override state, feature code or operator control, and the identity and time of the last authorized change. Clearing an override may reveal the schedule but does not prove the schedule is correct.

Follow nested conditions one at a time. A holiday exclusion, business-hours group and emergency closure can each choose a different destination. Do not flatten them into one broad range merely to make today's call pass; preserve the business-policy owner and a reset procedure for every manual control.

Test future boundaries without changing production time

Asterisk documents TESTTIME() for evaluating time logic at an alternate date, time and optional zone. Use it only in an isolated diagnostic channel or staging copy whose dialplan and version match the affected system; it changes the test channel's logical time, not the production host clock. Do not set the live server clock forward or invoke an unreviewed generated context on customer traffic.

Cover ordinary open and closed periods, opening and closing instants, weekdays, weekends, holidays, daylight-saving transitions where applicable, override activation and reset, and the restored scheduled state. Compare the chosen branch with the written business policy rather than only checking that a call reached some announcement.

Change one owner and verify the whole route

Correct only the demonstrated system timezone or synchronization owner, Time Group range, explicit condition timezone, holiday exclusion, override state or upstream route. Apply the change through FreePBX, preserve the prior value and define a rollback trigger. Avoid direct edits to generated Asterisk configuration.

Repeat an external call for each affected DID and every required boundary, confirming the inbound route, condition, selected branch and final destination. Verify that manual override indicators and reset instructions match actual behavior. No PBX, clock, time group, override, holiday, generated dialplan, route, destination or live call was tested for this guide.

Use the calendar-specific path for event-backed conditions

If the Time Condition is in Calendar mode, use the calendar event diagnostic to prove remote retrieval, local interval, group match and consumer state before changing the condition’s destinations.

Keep Wake Up Call scheduling separate from time-condition routing

A Wake Up Call uses a stored schedule and Asterisk call file; it is not evidence that a Time Condition matched or routed an ordinary inbound call.

Escalate from FreePBX objects to the exact loaded time priority

The Asterisk wrong-branch diagnostic proves which primitive, clock, timezone, timespec and target executed after the FreePBX route, Time Group and override state are known.

Keep FreePBX schedule state separate from an Asterisk epoch wait

The WaitUntil diagnostic isolates civil-time conversion, epoch, channel and result when custom dialplan introduces a wait.