Skip to main content
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.
FieldRequiredDescription
NameYesShort name for the rule (e.g., “Failed Bridge Transfers”)
DescriptionNoAdditional context about what this rule monitors
Enabled—Toggle to activate or deactivate the rule (default: enabled)
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:
OperatorDescription
EqualsExact match
Not EqualsDoes not match
ContainsValue contains substring
Not ContainsValue does not contain substring
Greater ThanNumeric comparison
Less ThanNumeric comparison
Greater Than or EqualNumeric comparison
Less Than or EqualNumeric comparison
Starts WithValue starts with prefix
Ends WithValue ends with suffix
  1. Enter the value to match against
  2. 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. CEL gives you full flexibility to express any condition. Example CEL expressions: 
// 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. 
// 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”
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

Integrations

Set up notification channels

Activity

Monitor rule matches in real time