Configuring Twilio Studio Flow Debugger Log Verbosity

Answer to the Core Questions

1. Can I get DEBUG‑level logs via the Executions Logs API? No. The API endpoint for fetching execution logs does not expose a verbosity parameter and returns the same level of detail that the Studio Debugger shows for the selected log level.

2. Is there a hidden feature flag or account setting that unlocks higher verbosity? No. Twilio does not provide a global or account‑wide flag to switch the Debugger’s log level beyond what the UI allows.

3. Are there plans to expose a verbosity option in the API? As of the latest public documentation, Twilio has not announced any roadmap items that add verbosity control to the Executions Logs endpoint. If you need more detail, you’ll have to rely on the UI or contact support for deeper diagnostics.

How to Enable DEBUG Log Level in the Studio Debugger

1. Open the flow you want to debug in the Twilio Console.
2. Click the bug‑icon in the top‑right corner of the canvas to launch the Debugger panel.
3. In the panel, click the gear‑icon (Settings).
4. Locate the Log Level dropdown. Options are:
   • Error – only error messages appear.
   • Warn – warnings and errors.
   • Info – normal execution steps and variable values.
   • Debug – detailed step‑by‑step execution, including variable snapshots and widget‑level logs.
5. Select Debug. The change takes effect immediately for the current session.
6. Run the flow. You’ll now see a richer set of messages in the Debugger panel.
7. To retain this setting for future debugging sessions, close the Debugger and reopen it; the chosen level persists until you change it again.

Exporting Logs for Support or Archival

After running a flow in Debug mode, you can export the log output by clicking the Export button in the Debugger panel. The exported file will contain the full DEBUG‑level details, which can be shared with Twilio support if you encounter an issue that the UI cannot resolve.

What to Do When the Debugger Still Lacks Detail

If the Debugger shows a generic error message (e.g., “Widget failed to load”) and no stack trace, consider the following:

• Check the widget’s configuration for missing required fields or environment variables. The error message often points to the missing key.
• Validate any external API calls or HTTP requests the widget performs; failures there may surface as generic errors.
• Use the Export feature to capture the full log, then compare the timestamps and variable values against the flow’s logic.
• If the issue persists, open a support ticket and attach the exported log; Twilio support can inspect the underlying runtime errors that the UI does not expose.

Follow‑Up Diagnostic Detail

To refine the recommendation further, could you share which widget or step in your flow is producing the generic error? Knowing the specific component will help determine whether the issue is a configuration problem or a deeper runtime exception.