Rule-Based Notifications (RBN) proactively alert you when key metrics in Alloy cross thresholds you care about—so you can catch issues like spikes in denials, drops in approval quality, or unexpected volume changes without constantly monitoring dashboards.
You can create three types of rules:
Count-based rules – trigger when a raw number of applications or evaluations meets a threshold
Percent-based rules – trigger when a percentage of applications or evaluations meet a condition, with a required minimum volume
Percent change rules – trigger when metrics deviate from your historical baseline behavior
This guide explains how to set up both, what each variable means, and best practices for using RBN effectively.
What You Can Monitor
You can create rules on:
Journeys or Workflows
Outcomes (e.g. Approved, Denied)
Tags (Workflow-only)
Rules evaluate activity over a rolling time window and notify you when conditions are met.
How to Create a Rule-Based Notification
Navigate to Settings → Rule-Based Notifications in the Alloy Dashboard.
Click Create Rule-Based Notification.
Enter a Name (and optional description) for your rule.
Select whether the rule applies to a Workflow or Journey, then choose the specific policy.
Write your rule using the rule builder (details below).
Save the rule. Alloy validates the rule when you save it — see Rule Validation & Rule Health below.
The rules list can be sorted by rule name or by the workflow/journey the rule applies to, making it easier to manage a large set of rules.
When the rule is hit, Alloy will:
Send an email notification to defined users
Show an in-dashboard notification
Attach a unique RBN token to the alert for investigation
Rule Types Explained
Rule-Based Notifications support three rule types: count, percent, and percent change. Each is designed for a different monitoring need.
Count-Based Rules
Count rules trigger when the number of applications or evaluations matching a condition reaches a threshold within a given time window.
Example
Notify me if 20 applications are denied over the last 30 minutes.
Key variables:
Metric: Applications or evaluations
Condition: Outcome or tag (e.g. Denied, Manual Review)
Count threshold: Minimum number required to trigger
Time window: Rolling lookback period (e.g. last 15 minutes, 1 hour)
When to use count rules:
Monitoring absolute spikes in volume
Catching system issues (e.g. sudden surge in failures)
High-volume, stable traffic patterns
Percent-Based Rules
Percent rules trigger when a percentage of applications or evaluations meet a condition and a minimum volume requirement is met.
Example
Notify me if 50% of applications are denied, with at least 30 applications, over the last 1 hour.
Key variables:
Percentage threshold: The percent of applications/evaluations that must meet the condition
Condition: Outcome or tag
Minimum count: Required volume before the rule evaluates
Time window: Rolling lookback period
Why minimum count matters:
The minimum count prevents false positives during low-volume periods (for example, 1 denial out of 1 application = 100%). The rule only evaluates once this minimum volume is reached.
When to use percent rules:
Application volume varies by time of day or day of week
You want signal consistency across peak and off-peak hours
Monitoring quality metrics like denial or approval rate
Percent Change Rules
Percent change rules track deviations from your normal baseline behavior. Instead of comparing against a fixed threshold, these rules compare current performance to historical averages.
Example
Notify me if the percent change of hourly evaluations with the Fraud Risk tag is 50% or more above my baseline average.
How baseline is defined:
Alloy calculates a baseline average using a 90-day rolling historical average for the selected metric
Baselines are calculated at the same granularity you select (hourly, daily, or weekly)
If you have less than 90 days of data, alerts may trigger more frequently until the baseline stabilizes
Key variables:
Granularity: Hourly, daily, or weekly
Metric: Applications or evaluations
Condition: Outcome or tag
Direction: Above or below baseline
Percent change threshold: How far from baseline the metric must deviate
When to use percent change rules:
Detecting anomalies relative to your normal behavior
Monitoring partner or traffic shifts
Catching gradual but meaningful changes that absolute thresholds may miss
Percent change rules can be applied to Workflows or Journeys and support tags and outcomes, just like count and percent rules.
Rule Validation & Rule Health
Rules are only useful while the things they reference still exist. Alloy validates your rules in two ways:
Validation when you save
When you create or edit a rule, Alloy checks that the target outcome, response status, or tag exists in the active version of the selected workflow or journey. If it doesn’t — for example, the rule references a tag that isn’t in the policy’s active version — the rule cannot be saved until the condition is corrected.
Flagging rules invalidated by policy changes
Workflows and journeys change over time, and a rule that was valid when created can silently stop matching anything — for example, if the tag it monitors is removed in a new workflow version. The Rule-Based Notifications list flags rules that have become invalid after a workflow or journey change, so you can spot and fix stale rules instead of assuming you’re covered.
When you update a workflow or journey, review your Rule-Based Notifications list for flagged rules and update their conditions to match the active policy version.
Rule Evaluation & Reset Behavior
Rules continuously evaluate activity within the defined time window.
Once a rule is hit, a notification is sent.
After triggering, the rule resets and begins monitoring again from zero.
Investigating a Triggered Rule
Every notification includes a unique Rule-Based Notification Token (e.g. RBN-abc123).
You can use this token to:
Click directly from the email to the filtered Application Queue
Filter the Application Queue by the RBN token
See exactly which applications or evaluations contributed to the alert
What you’ll see:
For greater-than (>) rules: all applications/evaluations that met the condition (e.g. all denials)
For less-than (<) rules: all applications/evaluations that did not meet the condition
This makes it easy to identify root causes, partner-specific issues, or model behavior changes.
Best Practices
Use count rules for absolute volume monitoring.
Use percent rules for quality or rate-based monitoring.
Always set a reasonable minimum count for percent rules.
Start with broader thresholds and tighten them as you learn your normal patterns.
Pair RBN alerts with saved Application Queue filters for faster triage.
After changing a workflow or journey, check the rules list for rules flagged as invalid and update them to match the new policy version.
Webhook Notifications
In addition to email and in-dashboard alerts, Rule-Based Notifications can also trigger webhooks.
This allows you to programmatically respond to alerts—for example, by paging an on-call system, creating an internal ticket, or triggering downstream automation.
How to enable webhooks for RBN:
Navigate to Settings → Webhooks and create or select an existing webhook endpoint.
When creating or editing a Rule-Based Notification, select the webhook you want triggered when the rule is hit.
Save the rule.
When the rule is triggered, Alloy will send a webhook event with details about the notification, including the unique RBN token for investigation.
For payload structure and event details, refer to the Alloy API documentation.
Notifications & Permissions
Email notifications are sent from [email protected]
Webhooks are delivered to the endpoint configured in Settings → Webhooks
Only users with appropriate permissions can create or edit rules
Notifications (email, dashboard, webhook) are sent to users or systems configured for the rule
Rule-Based Notifications help you stay ahead of issues without manual monitoring—giving you faster insight into changes that matter most.