Skip to main content
When Twilio runs into a problem while handling an SMS, voice, or other request, it logs an event in the Debugger at one of two levels: Error (Twilio could not process the request) or Warning (Twilio could still process it). Use the Error webhook in the Twilio Console to send Error-level events to Flashduty On-call:
  • Events with the same error code on the same Twilio account merge into one alert, for example a run of 11200 errors caused by your application URL returning 404
  • Warning-level events do not create alerts
The Error webhook is available in every Twilio region (US1, IE, and AU).

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Twilio and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Twilio and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Twilio

1

Set the Error webhook in Twilio

Where: Twilio Console › Monitor › Error webhookTwilio’s documentation places this setting under Monitor in the Console. Newer consoles may have moved it to Develop › Troubleshoot › Error Webhook; that location is not confirmed by Twilio’s official documentation. If you cannot find it, search the Console for “Error webhook”.Save.
2

Turn on the auto-resolve timeout

Where: Flashduty console › Channels › Configuration › Settings › Advanced SettingsDebugger events are one-time log entries. Twilio sends nothing when an error stops occurring, so these alerts never recover on their own. Closing the incident also closes its alerts; if the error is still occurring, the next event opens the alert again. See auto-resolve timeout.
3

Produce a real Error event and verify

Where: Twilio Console › Phone NumbersThe Error webhook has no “send test notification” button, so verify with a real Error event:
  1. Under Phone Numbers, open a number and set the A call comes in URL to an address that returns 404, such as https://example.com/not-found
  2. Call the number. Twilio fails to fetch the URL and logs error 11200 in the Debugger
  3. After a few seconds, an alert titled Twilio error 11200: ... appears in Flashduty
Restore the number’s original URL when you are done.Go back to Flashduty. If the integration shows a Latest event time, the setup works.

Payload

Twilio sends one Debugger event per request. The body is application/x-www-form-urlencoded, and Payload is JSON: Every alert also carries the label source=twilio, and its description links to the error code in the Twilio error dictionary (https://www.twilio.com/docs/errors/<error code>). Example title: Twilio error 11200: An attempt to retrieve content from https://app.example.com/voice returned the HTTP status code 404.

Alert key

Flashduty computes the Alert Key from AccountSid and Payload.error_code, not from the event ID Sid:
  • Events with the same error code on the same account merge into one alert. The alert’s title, description, and labels show the latest event
  • Different error codes, and different accounts (including different subaccounts), are different alerts
  • This matches how Twilio Alarms count errors per account and per error code

Status and severity

An Error event is rejected if it lacks AccountSid or Payload.error_code, or if Payload is not valid JSON.

FAQ

Twilio logs problems it could still process as warnings, such as TwiML validation warnings. They are frequent and rarely need the on-call engineer right away, so Flashduty accepts them without creating an alert. You can still see them in the Twilio Debugger.
Events with the same error code on the same account merge into one alert, whose event count grows instead of a new alert opening for each failure. With the auto-resolve timeout on, the incident closes after the timeout; if the error is still occurring, the next event opens a new alert.
No. Flashduty identifies the integration by the integration_key in the push URL and does not verify the X-Twilio-Signature header. Keep the push URL as secret as a key.

Troubleshooting

  • Errors appear in the Twilio Debugger but not in Flashduty: make sure the URL in the Error webhook setting (see the location note in step 1) is complete (including integration_key) and that the event level is Error
  • Requests are rejected (4xx): make sure the push URL belongs to a Twilio integration, not another integration
  • Alerts never close: turn on the auto-resolve timeout in the channel