Event Rules & Automation

Trigger actions on monitor, agent and custom events — the automation engine behind smart alerting.

What event rules do

Event rules turn "something happened" into "do this": when a monitor goes down, an agent reports a security event, or your own system emits a custom event, matching rules evaluate their conditions and fire their actions — notify a channel, open an incident from a template, or run an agent-side action.

Anatomy of a rule

Field Meaning
event_name Which event triggers it (monitor.down, monitor.up, agent events, or a custom name)
display_name Human label
classification public — visible on the status page, or team_only — internal events only
conditions JSON conditions evaluated against the event payload
monitor_id / agent_id Scope the rule to one monitor or agent
incident_template_id Auto-create an incident from a template when the rule fires
alert_channels Where notifications go
cooldown_seconds Minimum time between firings — flapping protection
is_enabled On/off 
curl -X POST https://api.shxrk.systems/api/v1/uptime/status-pages/<id>/events/rules \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "event_name": "monitor.down",
    "display_name": "Database outage page",
    "classification": "team_only",
    "monitor_id": "<monitor_uuid>",
    "incident_template_id": "<template_uuid>",
    "cooldown_seconds": 300,
    "is_enabled": true
  }'

Custom events

Your own systems can emit events — deploy markers, batch job results, capacity warnings:

curl -X POST https://api.shxrk.systems/api/v1/uptime/status-pages/<id>/events/emit \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "event_name": "deploy.started",
    "classification": "public",
    "title": "Deploy v2.4.1",
    "monitor_id": "<monitor_uuid>",
    "payload": "{\"version\":\"2.4.1\"}"
  }'

Emitted events land in the event log (GET /status-pages/:id/events/log) and trigger matching rules.

Safety boundaries

  • Rules that trigger agent-side actions (script execution, service restarts) require elevated permission both at creation and when the event fires — a member with alert permissions cannot escalate into remote execution
  • team_only events never reach public webhooks or the public status page
  • Cooldowns prevent a flapping monitor from firing the same rule in a loop

Testing rules

Rules can be tested against historical events before enabling — a backtest shows what would have fired, so a new rule does not surprise you in production.

PreviousDistributed TracingNextSLA Policies & Reports