Skip to main content
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. The rule builder explains every evaluation with an example based on your settings.
New alert rule form in the Observe console. Rule details with name, description, rule type Flow volume and a contact point. Rule configuration with flow type Login, outcome Complete, baseline 1 hour before, minimum expected average 20 and window last 10 minutes, followed by a timeline that explains how one evaluation compares the window with the baseline.

Rule builder for a flow volume rule: completed logins in the last 10 minutes against the hour before.

​
1. Rule types

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:
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: Outcomes: Complete (default), Incomplete, Skipped, Invisible and Visible, auto-skipped. The outcomes are explained in flow events. 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: The subflow types correspond to the subflows 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 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 are part of Corbado’s managed enterprise service. Corbado combines the anomaly analysis, 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.
Lower part of the rule form. Group by with Application selected and Browser, Operating system and two custom tags available, maximum alerts 50. Threshold configuration with a critical band below 25 and a warning band below 50. Recovery threshold switched on at 70 or above. Pending period 2 minutes and missing data shown as no data.

Grouping, severity bands, recovery threshold and timing of the same rule.

Anomaly detection alerts per discovered cohort, and finding incident uses the finding’s segment. Custom tags are the 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 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 to route the alerts to email, webhooks or PagerDuty.