Monitors

How to set up metric alerts in Slack. Configure threshold-based monitoring that notifies you when churn, MRR, or any metric crosses a limit.

How Monitors Work

A monitor is a skill with an alert trigger attached. Instead of posting results on a fixed schedule like scheduled reports, monitors check a condition and only notify when that condition is true. If nothing is wrong, your channel stays quiet.

The monitoring loop:

Alice runs the skill's query at the configured poll interval
The result is evaluated against your condition (e.g., count > 0, mrr < 40000)
If the condition is true: alice posts an alert to the configured Slack channel with the full result
If the condition is false: nothing happens -- no message, no noise
After firing, a cooldown period prevents repeated alerts for the same condition

Diagram showing poll, evaluate, notify flow for monitors — Monitors poll on an interval, evaluate a condition, and notify only when the condition is met.

This is the key difference from scheduled reports: monitors are event-driven. A scheduled report always posts, whether the data is interesting or not. A monitor only speaks up when something needs attention.

Setting Up a Monitor

Monitors are configured in the Triggers step of the skill builder. A skill can have both a Schedule trigger and a Monitor trigger simultaneously -- they operate independently.

Triggers step with Monitor trigger enabled, showing condition configuration — Enable the Monitor trigger and configure the alert condition, poll interval, and notification channel.

Step 1: Enable the Monitor Trigger

Click the Monitor card in the Triggers step. The card description reads: "Poll on interval and notify when a condition is met (e.g. churn > 5%)." When enabled, the configuration panel expands below.

Step 2: Set the Poll Interval

The poll interval determines how frequently alice checks the condition. Choose from:

Interval	Description	Best For
Every 5 min	Most responsive, highest query usage	Critical payment monitoring, real-time alerts
Every 15 min	Good balance of responsiveness and efficiency	Failed payments, churn risk
Every 30 min	Standard monitoring cadence	Most business metrics
Every hour	Lower frequency, lower query usage	Revenue thresholds, customer counts
Every 6 hours	Periodic checks	Daily trend monitoring
Daily	Once per day	Slow-moving metrics, compliance checks

More frequent intervals consume more query quota. A 5-minute interval runs 288 times per day, while an hourly interval runs 24 times. Choose the interval that matches the urgency of the metric.

Step 3: Define the Condition

The condition is the core of a monitor. It has three parts:

Field -- Which field from the query result to evaluate
Operator -- How to compare the field value
Value -- The threshold to compare against (not needed for the changed operator)

Alert condition builder showing field selector, operator dropdown, and value input — Define the condition: field, operator, and threshold value.

If your skill has been tested and alice has detected the result fields, you will see a dropdown of available fields. Otherwise, you can type the field name manually.

Alert Operators

Operator	Symbol	Description	Example
Greater than	`>`	Fires when field exceeds the value	`count > 0` -- alert when results exist
Greater than or equal	`>=`	Fires when field meets or exceeds the value	`churn_rate >= 5` -- alert at 5% or above
Less than	`<`	Fires when field drops below the value	`mrr < 40000` -- alert when MRR drops
Less than or equal	`<=`	Fires when field is at or below the value	`payment_success_rate <= 95`
Equals	`=`	Fires when field exactly matches the value	`status = past_due`
Not equals	`!=`	Fires when field differs from the value	`status != active`
Changed	`changed`	Fires whenever the field value differs from the previous check	`mrr changed` -- alert on any MRR movement

The changed operator is unique: it does not need a threshold value. It compares the current result to the previous check's result and fires whenever they differ. This is useful for detecting any movement in a metric, regardless of direction.

Condition Examples

count > 0          -- "Alert when there are any results"
mrr < 40000        -- "Alert when MRR drops below $40K"
churn_rate >= 5    -- "Alert when churn hits 5%+"
failed_count > 3   -- "Alert when more than 3 payments fail"
status != active   -- "Alert when status is not active"
mrr changed        -- "Alert on any MRR change"

Step 4: Set the Cooldown

The cooldown prevents alert fatigue. After a monitor fires, it will not fire again until the cooldown period expires, even if the condition remains true.

Default cooldown is 60 minutes. If your monitor checks every 5 minutes and the condition stays true, you get one alert per hour, not one every 5 minutes.

Adjust the cooldown based on urgency:

Short cooldown (15-30 min): Critical alerts like payment failures where you need persistent notification
Standard cooldown (60 min): Most business metrics
Long cooldown (240+ min): Informational alerts where once or twice a day is sufficient

Step 5: Select a Notification Channel

Choose the Slack channel where alert notifications will be posted. This works identically to scheduled report channel selection.

Channel selector for monitor notifications — Choose the channel for alert notifications. The bot must be a member of the channel.

Example Monitors

Churn Risk Alert

Notify #ops when any customers are flagged as high churn risk.

Skill: A combined query that joins Stripe past-due subscriptions with Supabase login data
Condition: count > 0
Interval: Every 15 minutes
Cooldown: 60 minutes
Channel: #ops-alerts

When the condition fires, the full churn-risk list is posted with action buttons to tag in Stripe or send a Slack DM.

MRR Drop Alert

Notify #revenue when monthly recurring revenue drops below a threshold.

Skill: Stripe MRR metric block
Condition: mrr < 40000
Interval: Every hour
Cooldown: 240 minutes (4 hours)
Channel: #revenue

Failed Payment Surge

Alert when multiple payments fail in a short window.

Skill: Stripe failed payments query for the last hour
Condition: count > 3
Interval: Every 5 minutes
Cooldown: 30 minutes
Channel: #payment-alerts

Trial Expiration Warning

Notify when trials are expiring soon and need attention.

Skill: Stripe expiring trials metric block
Condition: count > 0
Interval: Daily
Cooldown: 1440 minutes (24 hours)
Channel: #growth

New Dispute Alert

Alert immediately when a new chargeback or dispute is opened.

Skill: Stripe open disputes query
Condition: count changed
Interval: Every 15 minutes
Cooldown: 60 minutes
Channel: #finance

Using the changed operator here means the team is alerted whenever the dispute count changes -- whether a new dispute opens or an existing one resolves.

User Spike Detection

Alert when signups exceed normal levels, indicating a viral moment or bot activity.

Skill: Supabase query counting users created in the last hour
Condition: count > 50
Interval: Every 15 minutes
Cooldown: 60 minutes
Channel: #ops

How the Condition Is Evaluated

Alice evaluates the condition against the first row of the query result. This works naturally for:

Aggregate queries (COUNT, SUM, AVG): The single result row contains the metric value
Metric blocks: Return a single row with the computed metric

For multi-row queries, the condition evaluates against the first row. If you want to alert based on the number of rows returned, include a count column in your query:

SELECT COUNT(*) as count
FROM users
WHERE last_login < now() - interval '30 days'
  AND plan = 'pro'

Now the condition count > 0 fires when any matching users exist.

Parameters in Monitors

Like scheduled reports, monitors run without user interaction and use default parameter values. Every required parameter must have a default set, or the monitor check will fail silently.

Monitors vs. Scheduled Reports

Both automate skill execution, but they serve different purposes:

Aspect	Scheduled Report	Monitor
When it posts	Every time the cron fires	Only when the condition is true
Best for	Regular updates the team expects	Exceptions that need attention
Channel noise	Predictable, regular messages	Quiet unless something is wrong
Examples	Daily MRR summary, weekly revenue	Churn spike, payment failure surge
Configuration	Cron + timezone + channel	Poll interval + condition + cooldown + channel

A common pattern is to use both: a scheduled report posts daily metrics to #ops, while a monitor alerts #ops-alerts only when something crosses a threshold.

Managing Monitors

Viewing Active Monitors

Navigate to Dashboard > Skills and filter by the "Monitor" trigger type. Each skill shows whether its monitor is active and the last time it checked.

Disabling a Monitor

Open the skill, go to the Triggers step, and click the Monitor card to toggle it off. The condition, interval, and channel settings are preserved for when you re-enable it.

Run History

Every poll check is logged in the skill's run history, whether the condition was met or not. This lets you verify the monitor is checking correctly and see when alerts were triggered.

Plan Limits

Plan	Monitors	Poll Intervals
Free	3	All intervals
Pro	25	All intervals
Business	Unlimited	All intervals

Free plans include 3 monitors, which is enough to watch your most critical metrics. Pro plans support 25 monitors, covering a wide range of business metrics. Business plans have no limit.

All plans have access to every poll interval, including the 5-minute option.

Troubleshooting

Monitor not firing: Check that the condition is correctly configured. Run the skill manually with /alice <slug> and verify the result includes the field you are monitoring. If the field name does not match, the condition will never evaluate to true.

Too many alerts: Increase the cooldown period. A 5-minute poll with a 5-minute cooldown will fire repeatedly if the condition stays true. Set the cooldown to at least 4x the poll interval.

No alerts even though condition should be true: Verify the field name matches exactly. Field names are case-sensitive. Also check that the value type matches -- a string comparison on a number field will not work as expected.

Alert posts but data looks stale: The poll interval controls check frequency. If you set a 6-hour interval and the condition became true 5 hours ago, you will not be alerted for another hour. Decrease the interval for faster detection.

Scheduled Reports -- time-based automation for regular updates
Creating a Skill -- build a skill to monitor
Actions -- act on monitor alerts with one-click buttons
Parameters -- set defaults for monitor execution
Formatting Output -- format the alert message
Combined Queries -- monitor conditions across multiple data sources
Plans -- compare monitor limits across tiers

Was this page helpful?

Monitors

On this page