Debugging
Writes a timestamped line when the call passes through, readable for seven days in the plan's log. It never interrupts the call, even if the write fails.
In brief
| Outputs | one, always taken |
| Fields | Message, which accepts {{variables}} |
| Message length | 500 characters, truncated beyond that |
| Ceiling | 500 lines per day, for the whole installation |
| Retention | 7 days, then automatic deletion |
| Where lines are read | Dial plans, notepad icon on the plan's row |
| Effect on the call | none, even when the write fails |
The help text shown in the window is: "Writes a timestamped line to the debug log, viewable for 7 days from the dial plan list. Use {{variable}} to display the value of a variable. Never interrupts the call."
How it works
This is the tool that answers "why isn't this call doing what I expect." Place it where you have doubts, call, read the trace.
When the call passes through, the module writes one line: the date and time, the caller's number, and your message. The call then continues, with no perceptible delay and no announcement played. Even an impossible write does not interrupt it.
The message accepts {{variables}}, replaced at the moment of writing. This is the whole point: instead of just noting that a branch was taken, you read with which values it was taken. A message that contains none is still useful as a marker that the call passed through.
Reading is done from Dial plans, via the notepad icon on the plan's row. The Debug log page of this guide describes this screen: grouping by call, the Refresh button, and the display time zone.
The three limits to know
- A message is capped at 500 characters. Beyond that it is truncated, with no warning.
- The whole installation can write 500 lines per day. At the ceiling, a final line announces that the log is truncated, and nothing more is written until the next day. This ceiling applies to all your plans combined, not to a single one.
- Lines are kept for 7 days, then deleted.
What to fill in
| Field | What is expected | If you leave it empty |
|---|---|---|
| Message | the text to write, with the {{variables}} you're interested in | no line is written, and the call carries on as if nothing happened |
Steps
- Open the editor of the plan to observe.
- Place the Debugging module on the branch you doubt, and connect it in series: input from the previous node, output back to the rest of the path.
- Open it and write the Message. Name the branch rather than the obvious: "evening branch" tells you more than "here."
- Add the useful variables, copied from the Available variables panel, for example
entry={{entry}} name={{odoo_partner_name}}. - Click Save.
- Check that the module's output is indeed connected to the rest of the plan.
- Click Apply changes in the top banner.
- Call your number, taking the observed branch.
- Go back to Dial plans, click the notepad icon on the plan's row, and read the lines. Refresh rereads the log after a new call.
If it doesn't work
No line appears in the log. Four checks, in order: the Message is not empty, since an empty message writes nothing; the module is connected in the plan and not just placed off to the side; the plan has been saved and applied since; a call did indeed take this branch.
My message is cut off in the middle. A message is capped at 500 characters. Split it across two modules if you need more.
A line announces that the log is truncated. The daily ceiling of 500 lines has been reached, and nothing more will be written until tomorrow. Remove the Debugging modules that write on every call and keep only the ones for the current diagnosis.
Lines from ten days ago have disappeared. Retention is seven days. This is intentional, and there is no setting for it.
The call cuts off right after the module. It's not the Debugging module: it never interrupts the call. It's its single output that isn't connected to anything. Connect it to the rest of the plan.
How the call flow is built, explained in pictures
See the Dial plans page