LooplineGuide
/
Sign in

Automation rules

Turn a webhook from any outside system — monitoring, alerting — into a new ticket, or change an existing one's priority.

Settings → Automation rules

Turns an inbound webhook from any external system (monitoring, alerting, incident tools — anything that can POST JSON) into a created or updated ticket. Unlike Email Intake (which parses a fixed {from, subject, body} shape), this accepts arbitrary JSON — conditions read any field by dot-path. Owner/Admin only. (Rules that react to things happening to tickets inside the app — created, updated, commented on — live on a different page, Settings → Ticket automations.)

The webhook URL

One per org, shown above — copy it exactly as displayed rather than reconstructing it. Leave Monitoring tool on Generic / any other tool for the URL that takes any JSON, or pick a tool to get its own variant of the URL plus setup steps. Add more rules underneath it; a new rule applies to the very next event, no new URL needed. Regenerating invalidates the old URL (and every tool's variant of it) immediately.

A tool with no adapter of its own can name itself: fill in Custom provider name and the generic URL gains ?provider=your-tool; a rule condition source equals your-tool then matches only that tool's events.

Treat the URL as a secret — there's no separate signature/HMAC check, the token in the URL is the only authentication.

How a rule evaluates

Every event is checked against every active rule in the org whose Provider fits, not just one project. A rule left on Common — matches any source sees every event; a rule scoped to one tool sees only events sent to that tool's URL. Events sent to the generic URL reach Common rules only.

  • Conditions are AND-only — all must match. Need "OR"? Create two separate rules.
  • equals / contains compare the field's value as a string; exists ignores the value and just checks the field is present.
  • Create a new ticket — titled from a template with {{field.path}} placeholders, attributed to the rule's Acting user as reporter.
  • Update an existing ticket's priority — the only field it can change. It finds the ticket via its external reference (under Advanced).
  • Link to configuration item by this field (under Advanced, when Configuration Items is on) — the value at that path is matched against a configuration item's External ID, and the ticket is linked to it.

Correlating create → update

External reference is how a later event finds a ticket an earlier event created. On the create rule, whatever field you name under Advanced → Store this field as the ticket's external reference (e.g. alert.id) is stored on the new ticket. On the update rule, the same field name is read from that event and used to find it. If the two rules name different fields, the update will never find the ticket.

Rule 1 (create):  condition alert.status = firing   →  external ref: alert.id
Rule 2 (update):  condition alert.status = resolved →  external ref: alert.id  (same field!)

Monitoring adapters (CloudWatch, Azure Monitor, Sentry, PagerDuty, Datadog, Grafana, UptimeRobot/StatusCake)

Pick the tool under Monitoring tool above to see its URL (only tools your plan includes are listed). Each adapter normalizes its vendor's payload into a flat object before any rule runs — so a rule's conditions must use the normalized field names listed in each tab below, not the raw vendor field names from the original payload.

Use the CloudWatch webhook URL shown above (the plain webhook URL won't unwrap the SNS envelope). In the SNS console, create a subscription on your alarm's topic with protocol HTTPS and this URL as the endpoint.

  • SNS's subscription-confirmation handshake is confirmed automatically — nothing to click. It only auto-confirms genuine sns.*.amazonaws.com hosts, so a spoofed confirmation request is rejected rather than followed.
  • Once confirmed, every alarm state change (raw or SNS-wrapped) reaches your rules.
  • Requires the AWS CloudWatch Monitoring plan feature.

Normalized fields available to conditions:

  • alarmName, alarmArn — from AlarmName / AlarmArn
  • state, previousState — e.g. ALARM, OK, INSUFFICIENT_DATA (from NewStateValue / OldStateValue)
  • reason, region, stateChangeTime

Known limitations

  • A disabled rule is skipped before evaluation — it logs nothing in Recent activity, which looks identical to "the event never arrived." (An active rule whose conditions did not match is logged as skipped.)
  • Update action changes priority only — not status, title, or assignee.
  • No payload schema validation — anything with the URL can trigger rules with any JSON shape.