# November 4, 2026: Subconditions, alert history and 503 response

This update includes subconditions and the **First only** mode in event rules, plus an event type with the alert history. The events API now responds `503` when the rule cannot decide.

## Subconditions

A condition in an event rule now accepts subconditions, up to 3 levels below the rule. Subconditions are only evaluated when the condition's expression is met. The new standalone action, with no expression, runs whenever evaluation reaches it. Payment rules remain without subconditions.

For example, the `high_amount` subcondition, inside the `foreign_card` condition, tests `$amount > 1000` only on events with a foreign card. See [Subconditions](/en/rules/conditions/#subconditions).

## First only mode and Else

The new **Mode** applies to the rule and to each condition with subconditions. In **All**, every met condition runs its actions. In **First only**, evaluation stops at the first met condition. A **First only** level accepts an **Else** at the end. The editor warns when a row of that level may never be evaluated.

For example, the `blocked_customer` and `manual_review` conditions, followed by an **Else**, produce a single decision per event. See [Evaluation mode](/en/rules/conditions/#evaluation-mode).

## Comparison and simulation as a tree

Version comparison shows the rule as a numbered tree, with the **Added**, **Changed**, **Removed** and **Reordered** labels on each condition and action that changed. The simulation marks the rows the rule did not evaluate. On the rule page, the count of conditions met now leaves out the runs in which the condition was not evaluated.

See [Comparison and publishing](/en/rules/versioning/#comparison-and-publishing) and [Simulation](/en/rules/simulation/#result).

## Alert event type

Every account now has the `_alert` event type, with an event for each opening and each closing of a monitor alert. The alert history can be queried in **Explore**, measured by metrics and followed by monitors, like any other events. The history starts with this update and remains after the alert is no longer shown.

For example, select `_alert` in **Explore**, under the **More** menu, and split by **Monitor** to find the monitors that opened the most alerts in the month. See [Alert event type](/en/events/event_types/#alert-event-type).

## 503 response in the events API

When an internal outage keeps the rule from deciding, `POST /events` now responds `503`, with the `Retry-After` header, without recording the event. Resend the event after the interval given in the header, with no risk of duplication. The change is **compatible**: no field or response format changed, but the integration must handle the new code.

See [Errors](/en/api/technical-integration/#errors).

## Tor and cloud providers in the IP type

The IP address enrichment now identifies Tor network exit relays, with the `tor` value in the IP type, on IPv4 only. Google Cloud, Oracle Cloud, DigitalOcean and Linode addresses now get the `hosting` value, like AWS ones.

See [IP address data](/en/rules/actions/enrich/#ip-address-data).

## Subconditions through the agent

The AI agent connected via MCP now reads and builds rules with subconditions, standalone actions, **Else** and the mode of each level. In a simulation through the agent, each row that was not evaluated states the reason. The agent also lists a list field's items and adds, changes or removes items in batches.

Ask, for example: "In the draft of the sign-up rule on the store-us account, put the disposable email conditions inside a `suspicious_email` condition, in First only mode." See [Agents](/en/admin/agent/#operations).

## Other improvements

- **Rules**: the limit of rows per rule goes from 30 to 50. Conditions, standalone actions and **Else** count toward the limit. See [Limits](/en/limits/#rules-and-lists).