VoIP.info Troubleshooting

FreePBX Wake Up Call does not ring or plays at the wrong time

Trace one reminder through stored time, generated call file, Asterisk spool processing, call attempts, answer, prompt and confirmation before rescheduling it.

Reviewed 2026-10-15Current Sangoma Wake Up Calls guidance, FreePBX Hotel Wakeup release/17.0 metadata, configuration, call-file and feature-code source, plus current Asterisk call-file and filesystem documentation reviewed October 12, 2026; repository behavior and defaults do not establish the installed module, enabled feature code, effective settings, PBX timezone, stored job, generated file, spool processing, endpoint state, prompt, confirmation or call result, and no PBX, module, file, endpoint or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one reminder and classify the symptom

Choose one authorized non-emergency reminder and retain its job identifier, creation path, scheduling identity, destination, requested local date and time, repeat rule, language and current status. Record whether it rang early, late or not at all; rang the wrong destination; stopped after an attempt; played the wrong or no prompt; or was answered without human confirmation.

Do not delete and recreate the job first. A wrong stored epoch, missing call file, unreadable file, exhausted attempt, endpoint answer, voicemail answer, prompt failure and unconfirmed human delivery can produce the same user report while leaving different evidence.

Reconcile local time, timezone and the stored epoch

Compare the requested wall-clock time with the PBX timezone, host clock, NTP state, current daylight-saving offset and stored Unix time. For a repeated reminder, enumerate the generated occurrences around the affected date. A correct page display does not prove that the future file timestamp or host timezone matches the scheduler's expectation.

Correct the time owner once. Do not move the PBX clock, change timezone and reschedule in one step, because that destroys the evidence needed to identify which conversion was wrong. Preserve a control job outside the daylight-saving boundary when diagnosing seasonal errors.

Prove the saved job produced one complete call file

Match the module job and destination to the generated file, its modification time and its complete Channel, caller identity, wait, retry, application and data fields without exposing sensitive values. Confirm the effective Asterisk spool directory instead of assuming the default path.

Asterisk warns against writing directly in the watched outgoing directory because it can read a partial file. If the file is absent or incomplete, preserve permissions, ownership, filesystem capacity and the module error before retrying through the supported path. Do not hand-create a replacement that bypasses the module record or authorization boundary.

Follow spool pickup and every attempt to a terminal status

At the scheduled instant, correlate the call-file timestamp, pbx_spool pickup, originated channel, destination, ringing or rejection, answer timeout, retry counter and terminal Expired, Completed or Failed status. Asterisk defines maximum retries separately from the initial attempt, and retry timing begins after a failed attempt; calculate the actual attempt window from effective values rather than a remembered default.

If no channel was created, stay with spool visibility, file parsing, permissions and runtime module state. If a channel exists, preserve its technology cause and any SIP response before changing routes, registrations or endpoint settings. A failed reminder is not automatically an inbound-call or media defect.

Separate endpoint answer from prompt and human confirmation

After answer, verify that the configured application ran, the selected language and prompt files resolved, audio reached the endpoint, and the expected confirmation or snooze input was received. An answering machine, auto-answer device or upstream service can answer the originated call and let the call file complete without the intended person hearing or acknowledging it.

If the call rings but audio is silent, continue with prompt availability, format, channel language, SDP and RTP only after answer is proven. If the prompt plays but the user report remains “missed,” retain confirmation and human-acceptance evidence rather than increasing retries blindly.

Make one correction and prove schedule, delivery and cleanup

Correct only the demonstrated time, job, file-generation, permission, route, endpoint, prompt or confirmation fault. Repeat an authorized reminder far enough in the future to observe normal file generation, then retain scheduling, spool, attempt, answer, prompt and terminal evidence. Cancel a separate test job and confirm that no orphan file or later call remains.

Retest one busy or unanswered control without emergency or premium destinations. Restore the prior module setting if the control regresses, remove sensitive traces and apply the retention policy to archived call files. No live reminder, endpoint, human response or timing path was tested for this workflow.

A waiting channel is not a complete wake-up scheduling system

The WaitUntil guide keeps the held channel, target instant, return status and later origination or playback outcome separate.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.