Alerting basics
Choose useful alert conditions
Choose a condition your team can act on. Make missing data and repeat notifications part of the plan.
Three results, three different meanings
Queue a notification. If the next check still matches, notify again.
No notification. Resolve any open incident.
No notification. Keep any open incident unresolved and review History.
Missing data here means a NULL or empty query result, not a count of zero. COUNT(*) returns 0 when no rows match, so 0 < 100 is a match.
A useful alert asks a clear question and reaches someone who can act on the answer. Before you choose a threshold, decide what action a notification should trigger.
Start with an action
“Revenue changed” is hard to act on. “Yesterday’s completed order revenue is below our review threshold” gives a team a clearer starting point. Name the alert after the problem, and send it to the channel that owns the response.
Start with a few important metrics. For each one, write down the data source, the condition, the person responsible, and the next check they should make. An alert is a prompt to investigate, not proof of a cause.
Choose a window that matches your data
Kisu checks every 12 or 24 hours. Choose a metric that makes sense at that cadence. It is not a substitute for real-time incident detection or safety-critical monitoring.
If a daily import finishes in the morning, a query for the current day may see incomplete data. Consider the previous complete day or allow for the import delay. In BigQuery, define the time window in SQL. In Google Sheets, the aggregation covers all rows below the selected column header.
Make the comparison explicit
A BigQuery alert needs a single Boolean result. Instead of returning a revenue total alone, compare it with a threshold in the query. For Sheets, choose an aggregation, comparison, and numeric threshold in the alert editor.
Test values on both sides of the boundary. Decide whether a value equal to the threshold should match. Use a threshold based on your own normal range and business needs, not an arbitrary example.
Treat missing data as a separate outcome
A failed check is not a healthy result. A BigQuery NULL or empty result, or a Sheets column without numeric values, produces no data. These outcomes do not notify or resolve an open incident.
If missing data itself should trigger an alert, express that condition explicitly. For example, a BigQuery COUNT(*) comparison can return TRUE when a time window contains no rows. Review failures and no-data outcomes in History as part of your routine.
Plan for repeat notifications
Kisu queues a notification on every successful matching check, not only on the first match. A persistent condition can produce two scheduled notifications per day at a 12-hour interval, or one at a 24-hour interval.
A nonmatching result resolves the open incident without a notification. A later match opens a new one. Review noisy thresholds and pause alerts that no longer have an owner. Check notification status in History as well as the condition result.