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:
ACed70abd024d3f57a4027b5dc2ca88d5b-FIRES-ATc142bed7b38c4f8186ef41a309814fd2-2013-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 by visiting Twilio's Community Forums or browsing the Twilio tag on Stack Overflow.