Skip to main content
When something goes wrong on Twilio’s side of a call or a text, Twilio writes to its own error log and posts each entry to the engine. The engine keeps every entry and pushes the serious ones to the super admins, so a broken phone is noticed within a minute rather than when a customer complains.

What happens

  1. Twilio raises an error or a warning, for example “could not fetch the voice webhook” (code 11200) or “message blocked” (code 30044), and posts it to the engine.
  2. The engine checks Twilio’s signature on the post, then stores the entry in its Twilio alerts list: level, code, product and message.
  3. If the level is error, every super admin gets a time-sensitive push titled Twilio error 11200 (the code varies) with the message. Warnings are stored but page nobody.

What does not page anyone

  • A forged or stale signature on any Twilio post is refused with “forbidden” and a warning in the engine’s log. Nothing is stored and nobody is paged; Twilio then raises its own error for the failed post, and that arrives through the path above.
  • A call that fails is a call outcome, not an error. It is stored as a failed call and copied to the CRM’s call history like any other call.

If the push stops arriving

  • Read the engine’s list of Twilio errors in the SQL editor; it has no screen, and the table’s name is on Names. Rows since the problem began with no push behind them were warnings.
  • Check the person is a super admin. Only that role is paged.