Free Accounts & Free Advice

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:

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 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.

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.