> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mirador.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Rules
> Define conditions that trigger automated notifications
Rules are the core of automations. A rule defines **conditions** that are evaluated against your traces in real time. When a trace matches, Mirador sends notifications to every integration linked to the rule.
Rules are **project-scoped** — each rule belongs to a specific project and only evaluates traces within that project.
## Creating a Rule
Navigate to **Automations → Rules** and click **Create Rule**.
### 1. Name and Description
Give your rule a name that clearly describes what it monitors. The description is optional but helpful for team context.
| Field | Required | Description |
| ----------- | -------- | ------------------------------------------------------------ |
| Name | Yes | Short name for the rule (e.g., "Failed Bridge Transfers") |
| Description | No | Additional context about what this rule monitors |
| Enabled | — | Toggle to activate or deactivate the rule (default: enabled) |
### 2. Link Integrations
Select one or more integrations from the dropdown. When this rule fires, notifications are sent to **all** linked integrations simultaneously.
You can create a new integration inline by clicking the **Add Integration** button directly from the rule form — no need to leave the page.
### 3. Define Conditions
Conditions determine which traces trigger the rule. Mirador offers two modes for building conditions:
#### Visual Mode
The visual builder lets you construct conditions without writing code. It's ideal for filtering on trace metadata like tags, attributes, and chain names.
**How it works:**
1. Click **Add Condition** to add a new condition row
2. Select a **field** from the dropdown (fields are dynamically populated from your trace schema)
3. Choose an **operator**:
| Operator | Description |
| --------------------- | -------------------------------- |
| Equals | Exact match |
| Not Equals | Does not match |
| Contains | Value contains substring |
| Not Contains | Value does not contain substring |
| Greater Than | Numeric comparison |
| Less Than | Numeric comparison |
| Greater Than or Equal | Numeric comparison |
| Less Than or Equal | Numeric comparison |
| Starts With | Value starts with prefix |
| Ends With | Value ends with suffix |
4. Enter the **value** to match against
5. Use **AND** / **OR** to combine multiple conditions
You can also create **condition groups** to build complex logic — for example, `(tag = "bridge" AND chain = "ethereum") OR (tag = "bridge" AND chain = "polygon")`.
#### CEL Mode
For advanced conditions, switch to the **CEL editor** to write expressions in [Common Expression Language](https://cel.dev). CEL gives you full flexibility to express any condition.
**Example CEL expressions:**
```cel theme={null}
// Match traces tagged with "bridge" on ethereum
trace.tags.exists(t, t == "bridge") && trace.attributes["chain"] == "ethereum"
// Match traces where amount exceeds threshold
double(trace.attributes["amount"]) > 1000.0
// Match traces with errors
trace.events.exists(e, e.name == "error")
// Combine multiple conditions
trace.tags.exists(t, t == "swap") && trace.attributes["status"] == "failed"
```
The visual builder and CEL editor stay in sync — conditions built visually are converted to CEL under the hood. If you write a CEL expression that can't be represented visually, the form will stay in CEL mode.
### 4. Simulate the Rule
Before saving, use the **Simulate** button to test your rule against existing traces in your project.
The simulation panel shows:
* **Number of matching traces** found
* **Trace name** for each match
* **Match reason** explaining why the trace matched
* **Link to trace** for quick inspection
This helps you validate that your conditions are correct and not too broad or too narrow before going live.
### 5. Save
Click **Save** to create the rule. It will immediately begin evaluating new traces if enabled.
## Managing Rules
### Enable / Disable
Toggle a rule on or off from the rules list using the switch control. Disabled rules stop evaluating traces but retain their configuration.
### Editing
Click the **edit** button on any rule to modify its name, description, conditions, or linked integrations. Changes take effect immediately on save.
### Deleting
Click the **delete** button and confirm to permanently remove a rule. This does not delete any linked integrations.
## Best Practices
### Start Specific, Then Broaden
Begin with narrow conditions targeting a known issue. Once you're confident in the rule's behavior, expand the conditions to cover more cases.
```cel theme={null}
// Start specific
trace.tags.exists(t, t == "bridge") && trace.attributes["chain"] == "ethereum" && trace.attributes["status"] == "failed"
// Then broaden
trace.tags.exists(t, t == "bridge") && trace.attributes["status"] == "failed"
```
### Use Simulation Before Saving
Always run a simulation to verify your rule matches the right traces. A rule that's too broad will generate noisy alerts; one that's too narrow will miss events.
### Name Rules After What They Detect
Good rule names make the Activity feed easy to scan:
* "Failed Bridge Transfers"
* "High-Value Swaps (> \$10k)"
* "Ethereum Gas Spikes"
### Link Multiple Integrations for Critical Rules
For high-priority rules, link both a Slack integration and an email integration to ensure the right people are notified even if one channel is missed.
## Next Steps
Set up notification channels
Monitor rule matches in real time