How do Alerts work?
Alerts are based on CRON schedules, so if you create an alert at 1:12 PM UTC with a schedule of every 30 minutes, it WILL NOT run at 1:12 1:42 2:12 UTC, it will instead run at 1:30 2:00 2:30 UTC, and so on.
This is true for all the default schedules.
List Based Alerts
These alerts notify you when a new row is returned (the result in this case) from the SQL query you define. A column with unique values for each row (let's call this the unique value column), chosen by you, is used to determine if a row is new.
An example - Define your SQL query to return the list of all undelivered packages and set the alert to trigger when a new package id is returned from the query. We schedule this alert to run every hour.
The SQL query for the above example would look like this:
SELECT package_id, assigned_partner, is_delivered FROM packages_table WHERE is_delivered = FALSE AND timestamp_column > now() - interval '65 minutes'
We recommend creating a time period constraint in the SQL queries for these alerts based on the schedule you choose. You can see that in the above example, we have constrained the packages we are querying to be from the last 65 minutes since the alert is going to run every hour.
An interval smaller than the schedule would mean that you will miss out on a few undelivered packages and an interval bigger than the schedule would lead to the same data being queried unnecessarily. Ideally, the time period constraint should be equal to the alert schedule + a short buffer time (to account for query execution time and computation delays).
Here are a few more pointers to keep in mind when creating list-based alerts:
The unique value column should be set to the table’s primary key or a column that is never repeated and uniquely identifies as a row.
Only return the columns that are necessary, to make the queries more efficient.
Explore your data and use cases to determine the right schedule. The schedule (and the time period constraint in the SQL query) should be set based on how often rows are being added to that table. A more frequent schedule will put unnecessary strain on your database/ warehouse, and a less frequent schedule will create a lot of incidents in one go.
Miscellaneous
1. How should I name my Alerts?
An alert’s name should concisely describe the use case/ action that the alert is tracking. We don't recommend adding details of the alert (such as the threshold value) in its name, these can be added in the templated incident names instead.
A couple of examples are: High number of delayed orders and Package undelivered
Keeping the alert names short and to the point will ensure that your alert notifications are easy to read and don't contain redundant data.
How should I decide my Alert Schedule?
Apart from the business use case of your alert, its schedule should be decided while keeping the following factors in mind:
Update the frequency of the data being queried
How often would your team look at and act on the alert incidents
The slowest of these factors would be the ideal schedule for the alert.
What should I keep in mind while writing my Queries?
While you can just drop in any existing query you have written down for your use case, it’s a good idea to optimize it based on the schedule. The following pointers can help you do so:
Only return the columns that are necessary, to make the queries more efficient.
For list-based alerts, make sure to return the primary key or a column that is never repeated and uniquely identifies as a row.
Unless the use case requires not having one, always include a time constraint in your query. This will reduce the load on your database/ warehouse.
The time period constraint should be equal to the alert schedule + a short buffer time (to account for query execution time and computation delays).
Blazing-fast operations minus all the constant firefighting👨🚒Learn how to set up a control tower for your operations in under 15 minutes ️🔥
...with Locale for modern ops teams |