Learn more with Workshops and Technical Sessions

App Monitor Triggers

App Monitor Triggers are webhooks that notify your application or external monitoring service when errors exceed daily, monthly, or yearly thresholds. You can create new Triggers in the App Monitor in the Account Portal.

For example, you can set an App Monitor Trigger to fire a webhook when the first or 100th error occurs in a day. Additionally, you can configure Triggers on specific error codes for finer monitoring detail.

As soon as the error count exceeds the TriggerValue, the trigger will fire and Twilio will make an asynchronous HTTP request to the App Monitor’s Trigger URL. This request will typically fire within a minute of exceeding the threshold.

Request Parameters

The parameters Twilio passes to the App Monitor Trigger URL are as follows:

AccountSidYour Twilio account id. It is 34 characters long, and always starts with the letters AC.
AppMonitorTriggerSidThe unique identifier of the App Monitor Trigger that fired.
DateFiredWhen the App Monitor Trigger fired, in UTC.
TimePeriodThe period of time over which the Trigger counts errors, one of daily, monthly, or yearly. For instance, a daily TimePeriod would reset the error count every day. Time periods are in UTC.
LogAn integer representing the log level of the entry observed: 0 is ERROR, 1 is WARNING.
ErrorCodeA unique error code for the error condition. You can lookup errors, with possible causes and solutions, in our Error Dictionary.
DescriptionA description of the error the Trigger was watching.
TriggerValueThe error count at which the App Monitor Trigger fires.
CurrentValueThe current error count for the defined time period (day, month, year) that the App Monitor Trigger is watching.
IdempotencyTokenA random token generated by Twilio, and guaranteed to be unique for this particular firing of this App Monitor Trigger. See Best Practices with App Monitor Trigger Webhooks.
Best Practices with App Monitor Trigger Webhooks

When implementing Trigger URL handlers take into account that it is possible that they may receive the HTTP request more than once. Services that handle duplicate requests and return the same response are called idempotent. We give you an IdempotencyToken that is unique for each App Monitor Trigger webhook request.

Example of a Recurring daily Usage Trigger's IdempotencyToken fired on 2012-10-04:

You can keep track of the IdempotencyToken to properly handle requests to your service and prevent them from performing the same operation twice. For instance, if your App Monitor Trigger sends alerts to your on-call team to notify them of an issue with your application, you’d want to be sure you didn’t send multiple alerts.

You can follow the test-and-set pattern to implement idempotent services. In short, you would test for the existence of the IdempotencyToken before processing your application's logic. This allows your application to handle already existing tokens and choose the next appropriate step.