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. In the overview’s Rules view, filter by rule type or contact point and inspect each rule’s evaluation hours. These filters apply to the rule list, not the individual alert list.
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 all logins in the rule’s engaged population. This population requires a qualifying subflow or nested flow and excludes automated-test traffic. A resolved decision alone does not qualify for this metric, although it can satisfy the broader engagement filter. Engagement does not necessarily mean deliberate user interaction. 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. Each time series can expose up to 20 configured custom tags; the rule offers the tags available in its source series. Filter groups: narrow a flow-volume or subflow-volume rule to the exact dimension combinations you want to watch. Choose grouping dimensions first, then select up to 50 complete combinations. An empty selection watches all combinations. The picker offers combinations observed in the last 24 hours. Its suggestions describe recent traffic, not the rule’s evaluation window or historical retention. 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, a firing alert stays firing and sends no notification. A pending alert returns to normal, so its pending period starts again when evaluation resumes. Evaluation history marks the missing value as outside evaluation hours, separately from missing traffic. Set weekly time ranges in 15-minute steps on the rule. The rule uses the project timezone. Ranges stay within one day; split an overnight schedule into two ranges. An override for one exact group can use different hours and an optional IANA timezone, for example Australia/Sydney for one market. Omit that timezone to follow the project timezone, or choose At any time to evaluate that group around the clock. Groups without an hours override inherit the rule schedule. 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. The Rules view’s Last 7d bars summarize each day’s evaluation states within evaluation hours. Hover for counts and the separate outside-hours total, or open the rule’s statistics for detail. Today’s bar is partial. 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. Evaluations outside their group’s evaluation hours are counted separately as Outside evaluation hours, rather than as the alert’s retained status. 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.

​
13. Simulate before saving

For Flow volume and Subflow volume, use Simulate the last 7 days in the rule form to evaluate your current settings against stored project data, once per minute. Simulation includes thresholds, pending periods, recovery, minimum expected volume, evaluation hours and segment overrides. It does not save or activate the rule, send notifications or apply contact-point delivery hours. Inspect the firings by group and hour, then select a group to see its values and status history. Adjust the settings and choose Simulate again. Repeated runs keep the same end time so you can compare settings against the same period. Results are marked when the settings differ from the last simulated configuration. Fix highlighted validation errors before retrying. Missing series or failed evaluations limit the result; a failed simulation is not evidence that the rule would never fire. Historical results help tune a rule but do not guarantee future behavior. Continue with notifications to route the alerts to email, webhooks or PagerDuty.