Alert Triggers

Alert Triggers can notify you via a webhook when errors exceed daily, monthly, or yearly thresholds. You can create and configure Alert Triggers in the Console's Developer Center.

For example, you can set an Alert 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 grained monitoring.

As soon as the error count exceeds the TriggerValue, the trigger will fire and Twilio will make an asynchronous HTTP request to the Alert Trigger’s webhook 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:

Parameter Description
AccountSid Your Twilio account id. It is 34 characters long, and always starts with the letters AC.
AppMonitorTriggerSid The unique identifier of the App Monitor Trigger that fired.
DateFired When the App Monitor Trigger fired, in UTC.
TimePeriod The 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.
Log An integer representing the log level of the entry observed: 0 is ERROR, 1 is WARNING.
ErrorCode A unique error code for the error condition. You can lookup errors, with possible causes and solutions, in our Error Dictionary.
Description A description of the error the Trigger was watching.
TriggerValue The error count at which the App Monitor Trigger fires.
CurrentValue The current error count for the defined time period (day, month, year) that the App Monitor Trigger is watching.
IdempotencyToken A 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 Alert 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.

Need some help?

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.