Rules & Automation

Rules determine how tiles react to incoming events. Create powerful automation by combining conditions and actions to update tile states, trigger notifications, and execute webhooks.

How Rules Work

  1. An event arrives via webhook
  2. The system finds all tiles monitoring that project and event type
  3. For each tile, rules are evaluated in priority order
  4. The first matching rule's actions are executed
  5. The tile state and content are updated
  6. Notifications are sent if configured

Rule Conditions

Field Matching

Match against any field in the event:

  • Event name (e.g., deploy_finished)
  • Event attributes (e.g., attributes.environment)
  • Severity levels
  • Custom fields

Operators

Text Operators:

  • • equals
  • • not_equals
  • • contains
  • • starts_with
  • • ends_with

Numeric Operators:

  • • greater_than
  • • less_than
  • • greater_or_equal
  • • less_or_equal
  • • between

Special Conditions

  • Always: Matches every event (useful for catch-all rules)
  • Exists: Checks if a field is present
  • Is Empty: Checks if a field is null or empty

Rule Actions

  • Set State: Change tile to OK, Warning, Error, or Info
  • Update Content: Set tile title, message, or custom fields
  • Trigger Notification: Send alerts via configured channels
  • Execute Webhook: Call external APIs or services
  • Add to Timeline: For deploy tiles, add to visual timeline
  • Update Metrics: For metric tiles, update values and thresholds

Example Rules

Deployment Success

Condition: name equals "deploy_finished"
Action: Set state to "OK"
        Update message to "Deployed {attributes.version}"

High CPU Alert

Condition: name equals "cpu_usage" 
           AND attributes.value greater_than 80
Action: Set state to "Warning"
        Send notification "High CPU: {attributes.value}%"

Service Down

Condition: name equals "http_check"
           AND attributes.is_up equals false
Action: Set state to "Error"
        Send notification "Service down: {attributes.url}"
        Execute webhook to PagerDuty

Rule Priority

Rules are evaluated in priority order (highest first). The first matching rule wins.

Example priority ordering:

  1. Priority 100: Critical error conditions
  2. Priority 50: Warning conditions
  3. Priority 10: Success conditions
  4. Priority 1: Default/catch-all rule

Best Practices

  • • Start with simple rules and add complexity as needed
  • • Use high priority for error conditions
  • • Always have a catch-all rule with low priority
  • • Test rules with sample events before deploying
  • • Use descriptive names for rules
  • • Group related rules together
  • • Document complex rule logic

Next Steps