> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corbado.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure Alert Rules
> Rule types, supported flow and subflow types, funnel conversion change, anomaly detection and finding incident rules, grouping dimensions, thresholds, business hours and timing for Corbado Observe alert rules.
An alert rule measures one number per group over a time window, compares it with severity bands and notifies a contact point when a group breaches. Create rules in [**Observe → Alerting**](https://app.corbado.com/observe/alerting). The rule builder explains every evaluation with an example based on your settings.
## 1. Rule types
| Rule type | Measures | Windows | Evaluated |
| - | - | - | - |
| **Flow volume** | Flows of one type in the window as a percentage of what the baseline predicts | 1, 5, 10, 15, 30 or 60 minutes | Every minute |
| **Subflow volume** | Subflows of one type in the window as a percentage of what the baseline predicts | 1, 5, 10, 15, 30 or 60 minutes | Every minute |
| **Login success rate** | Completed logins divided by engaged logins | 1, 3, 6 or 12 hours, 1 or 3 days | Every 5 minutes, on complete hours |
| **Funnel conversion change** | Conversion between two funnel nodes compared with an earlier period | 1 or 6 hours, 1 day | Every hour |
| **Anomaly detection** | Changes of one funnel node across its cohorts compared with an earlier period | 1 or 6 hours, 1 day | Every hour |
| **Finding incident** | Affected users of a critical finding per day or estimated per week, against the severity levels agreed with you | - | Every hour |
The builder offers a rule type, flow type or subflow type once your project has the data for it. If a type you need is missing, contact Corbado to enable it for your project.
## 2. Flow volume
Flow volume answers whether the expected number of flows still arrives. It counts the flows of one type that ended in the selected outcomes and compares the window with the baseline window right before it:
```text theme={null}
expected = baseline count × window ÷ baseline window
value = window count ÷ expected × 100
```
With a 10-minute window, a 1-hour baseline and 6,000 completed logins in that hour, the rule expects 1,000. A critical band at `below 25` fires when fewer than 250 arrive.
**Supported flow types:**
| Flow type | Covers |
| - | - |
| **Login** | Existing user authentication, across every method |
| **Signup** | Account creation |
| **Recovery** | Account and credential recovery |
| **Enrollment** | Authenticator enrollment, for example a passkey setup prompted after login |
**Outcomes:** `Complete` (default), `Incomplete`, `Skipped`, `Invisible` and `Visible, auto-skipped`. The outcomes are explained in [flow events](/corbado-observe/tracking/flows#2-3-flowfinished). Counting `Incomplete` turns the rule into a spike detector for failing journeys.
**Baseline:** 30 minutes, 1 hour (default), 2 hours or 3 hours before the window. A short baseline follows the daily curve closely. A longer one smooths short bursts.
## 3. Subflow volume
Subflow volume works like flow volume for a single method or step. Use it for partial defects that the overall login volume hides, for example social login failing while passkey and password logins keep the total stable.
**Outcomes:** `Completed` (default) or `Incomplete`.
**Supported subflow types:**
| Group | Subflow types |
| - | - |
| **Login methods** | Passkey Login, Password Login, Social Login, SSO Login |
| **One-time codes and links** | Email Link, Email OTP, SMS OTP, TOTP, App Confirmation |
| **Identifier and data** | Provide Identifier, Provide Data |
| **Credentials** | Passkey Enrollment, Passkey Deletion, Password Set, System Credential |
| **Device binding** | Key Signing, Key Registration, Trusted Device Enrollment, Trusted Device Check |
| **Journey control** | Flow Reset |
The subflow types correspond to the [subflows](/corbado-observe/tracking/subflows#3-subflow-types) you send or Autocapture records. Decisions are not available because they have no completion to count.
## 4. Login success rate
Login success rate divides completed logins by logins the user actually engaged with. Only logins the user interacted with count.
The rule reads hourly data and judges an hour once it is complete and final, about 10 minutes after it ends. Use it for steady quality signals, such as "login success on Chrome stays above 90%", and use the volume rules for fast outage detection.
## 5. Funnel conversion change
Funnel conversion change turns the [funnel history](/corbado-observe/overview/analytics#follow-a-change-over-time) into alerts for one known step. Pick a start node and a target node, for example identifier submitted to login completed. The value is the relative change of that conversion against the comparison period.
**Comparison period:** the previous day, the same weekday last week (default) or the average of the same weekday over the last four weeks.
## 6. Anomaly detection
Anomaly detection watches one funnel node and scans its cohorts across browser, browser version, OS and your custom tags, like **Find changes** in the funnel history. It alerts per cohort on a movement, a new gap or a persistent gap against the rest of the traffic, for example:
* **Passkey login on a new browser release:** completion of passkey login drops on Chrome 150 on Android while all other browsers stay stable.
* **Rising fallback:** more journeys reach the password fallback after a failed passkey attempt on one iOS version.
* **New route:** a share of logins suddenly continues into recovery after the identifier step in one market.
* **Market gap:** one market's social login completion falls clearly below the other markets.
* **Lost autofill:** the share of logins completed through autofill drops on one password manager or OS.
**Comparison period:** the same options as funnel conversion change, the same weekday last week by default.
## 7. Finding incident
[Findings](https://app.corbado.com/observe/analytics/findings) are part of Corbado's managed enterprise service. Corbado combines the [anomaly analysis](/corbado-observe/alerting/overview#3-anomaly-analysis-and-findings), observed errors, funnel changes and your new releases, checks them against the raw journeys and your source code or minified bundles, and publishes the result as a finding:
* **Segment and impact:** who is affected, compared with which group, and the estimated affected users and lost completions.
* **Errors:** the errors involved and their classification, for example a client-side WebAuthn error, a backend rejection or a third-party failure.
* **Verification:** manual tests or automated test runs that reproduce the problem and later confirm the fix.
* **Action:** what happens, how to reproduce it and who has to act, for example your frontend, your backend, a third party or the platform vendor.
When a finding is critical, it can also alert. The Corbado team or an automatic process activates the finding incident rule. Together we agree how many affected users per day, or estimated per week, trigger which severity in your system.
## 8. Group by dimension
Grouping creates one alert per combination of values. Each alert has its own state, pending clock and history, so a drop on one browser fires without waiting for the others.
| Dimension | Flow volume | Subflow volume | Login success rate | Funnel conversion change |
| - | :-: | :-: | :-: | :-: |
| **Application** | ✓ | ✓ | ✓ | ✓ |
| **Browser** | ✓ | ✓ | ✓ | ✓ |
| **Operating system** | ✓ | ✓ | | ✓ |
| **Login method** | | Already split, one method per rule | ✓ | |
| **Custom tags** | ✓ | ✓ | ✓ | ✓ |
Anomaly detection alerts per discovered cohort, and finding incident uses the finding's segment. Custom tags are the [tags](/corbado-observe/tracking/tags) your project uses for alerting, such as market, product or touchpoint. Up to six tags are available per project.
**Maximum alerts:** a rule creates at most 50 alerts by default, configurable up to 500. If grouping produces more combinations, the whole rule stops with an error, so a partly watched rule always shows up. Combine fewer dimensions or raise the limit.
## 9. Thresholds and severities
A rule carries one or more severity bands: `critical`, `warning` and `info`. Each band compares the value with a threshold, for example `is below 25`. The most severe matching band wins, and an alert that worsens from warning to critical sends an escalation.
**Recovery threshold:** an optional, more lenient value an alert has to reach before it resolves, for example `is at or above 70`. Without it, a value that hovers around the threshold fires and resolves repeatedly.
**Pending period:** how long a breach has to hold before the alert fires. Volume rules offer 1 to 30 minutes and default to 2 minutes. Login success rate offers 10 minutes to 6 hours. "Fire on the first breach" skips the pending period.
**Minimum sample:** volume rules use a minimum expected average per window, login success rate a minimum number of engaged logins. A group below the minimum produces no value and follows the configured missing-data policy. About 20 flows per window is a good starting point for volume rules.
**Missing data:** what an alert does when its group has no value. Choose between showing no data (recommended), treating it as normal, treating it as firing or keeping the last status. No data stays distinct from a measured zero.
## 10. Business hours
Business hours define when a rule judges its groups. Outside them, for example at night in a market with almost no traffic, a group pauses: it neither fires nor resolves, and an open alert keeps its state until the hours start again.
Set business hours on the rule with a timezone and weekly time ranges in 15-minute steps. For globally active businesses, business hours also apply per alert:
* **Timezone per group:** when a rule is grouped by a market or country dimension, choose **Timezone from dimension** and map each value to a timezone. Country codes are mapped automatically. One rule "Monday to Friday, 07:00 to 22:00" then follows local time in every market, without a rule per timezone.
* **Hours per group:** an override can set its own business hours, for example a 24/7 core market inside a rule that otherwise sleeps at night.
Business hours decide whether an alert is judged. [Delivery hours](/corbado-observe/alerting/notifications#5-delivery-hours) on a contact point decide whether a notification is sent. Use business hours for quiet periods of your traffic and delivery hours for the working hours of a team.
## 11. Overrides per segment
An override applies different thresholds, recovery, pending period, missing-data handling, minimum sample or business hours to one exact group. Use it when one segment behaves differently, for example a core market that needs a stricter band or a small application that needs a higher minimum sample. The window, baseline and grouping stay the same for the whole rule.
## 12. Timing and data delay
Flows arrive two to three minutes after they start, so volume rules end their window three minutes before the evaluation. If processing on Corbado's side falls behind, the window and its baseline move back by the same amount. A processing backlog therefore stays out of your values.
Login success rate reads complete hours only. An outage shows up in the hour after it starts, which is why volume rules are the better choice for fast detection. Funnel conversion change and anomaly detection evaluate complete hours as well.
After the first week, adjust thresholds per segment with overrides. The rule's Statistics tab summarizes normal, pending, firing, no-data and error states in project-timezone buckets. Rule health is shown separately from the alerts: a rule that cannot be evaluated, for example because a grouped tag was removed, shows up as an error.
Continue with [notifications](/corbado-observe/alerting/notifications) to route the alerts to email, webhooks or PagerDuty.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.