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.

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.

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 and Simulation.

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.

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.

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.

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.

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.