Build a Trend Spike automation

Trends can detect that a tag is spiking, but on its own it only shows that on the Trends page — somebody has to be looking at it. The Trend Spike Detected trigger turns a detected spike into an automation event, so a rule can react to it the moment it’s raised: filter on how severe or what kind of spike it is, then hand off to whatever action you want — a Slack DM, an email, a webhook, an assignment.

Trends itself doesn’t notify anyone. It raises the trigger; delivery is whatever action you wire up in the same rule.

Before you start

• Admin permissions to edit automation rules.
• Your tenant must have the Trends beta flag enabled. Without it, Trend Spike Detected won’t appear in the trigger list at all — the same way the picker hides Bug Reports behind its own gate — and the AI rule builder won’t offer it either, since it draws from the same trigger list. If you don’t see it, ask whoever manages betas for your tenant to turn Trends on first.
• A read of What are Automations? if you’re new to the builder.

Steps

1. Open the rules page. Go to Settings → Automation Rules. It opens on the Rules tab; the other two tabs are Manual Executions and Run History.

2. Start a new rule. Click New Rule, then pick the Manual Builder card on the screen that opens (the alternatives there are the AI builder and the templates).

3. Pick the trigger. Select Trend Spike Detected from the trigger list, under the Trends group. If it’s missing, your tenant’s Trends beta flag isn’t on — see “Before you start.”

4. Add conditions. This is where a Trend Spike rule earns its keep — instead of alerting on every spike, narrow it down. The condition panel exposes trend-specific fields, including:

   
   Severity — how strong the spike is. Today it has exactly one option, Spike: the page’s softer rising band and its recurring patterns never reach an alert, so they are not offered as filter values.
   Indicator — what spiked: Total volume or Tag. There is no Topic option. Trends detects topic spikes and shows them on the page, but no topic alert is dispatched while those groupings are under review, so a rule can never fire on one.
   Detector — which detector raised it: Volume or Established label.
   Kind — New incident (open) or Update (it worsened) (update). It is the alert’s lifecycle state, not what kind of thing spiked.
   Observed count — the count that crossed: customers on a label alert, conversations on a volume alert.

These are a handful of the 13 fields now filterable on this trigger — build the combination that matters to you, for example Indicator is Tag AND Kind is New incident, to hear about a brand-new tag spike but stay quiet as it worsens.

5. Add a branch and actions. Use an Always branch (or split by condition if you want different destinations for different severities), then add the action that actually delivers the alert — for example Send Slack DM. The trigger only tells you a spike happened; you choose what happens next.

6. Write the message with trend.* merge tags. In the action’s message body, pull in details about the spike instead of typing them by hand:

   
   trend.severity — the severity level.
   trend.indicator — the metric that spiked.
   trend.detector — the detector that raised it.
   trend.kind — whether this is the first alert about the incident (open) or an update because it worsened (update).
   trend.label — the tag that is spiking.
   trend.headline — the evidence sentence, computed from the counts. Lead your message with this one.
   trend.observed — the count that spiked. For a label alert this counts customers; for a volume alert it counts conversations.
   trend.expected — the usual count for a window this long, in the same unit as trend.observed.
   trend.windowTotal — the number of conversations in the window, always.
   trend.timesUsual — the effect size, as a multiple of the usual rate.

There are more — trend.why, trend.excess, trend.shareOfWindow, trend.window, trend.channels, trend.onsetAgo, trend.detectedAt, trend.summary and trend.url. The picker lists them all with an example value for each.

Watch the units. trend.observed and trend.windowTotal are not always counting the same thing, so don’t build your own ratio out of the two — use trend.shareOfWindow if you want a share.

7. Name and save, then enable the rule.

What “spike” actually triggers

A couple of behaviors are worth knowing before you rely on this for incident response:

• One message per incident. The trigger fires once when a spike is first detected, not once per detection cycle — the alerting logic looks for real evidence spread across non-overlapping arrival windows, not repeated reads of the same sliding window.
• Updates only when it gets materially worse. If the same incident is still open, your rule fires again only if the spike has meaningfully worsened since the last message that actually went out — not on every recheck. Once it stops worsening, the rule goes quiet for that incident.
• Delivery is not automatic. Nothing is sent unless your rule’s action sends it. Trend Spike only raises the event; a Slack DM (or any other action) is a separate step you configure in the same rule.

Verify it worked

Wait for (or force, in a lower environment) a tag to cross your configured indicator thresholds. Check Run History on the rules page — it filters by status and date range only, so find your rule by name in the Rule column. You should see one run for the incident, with its actions listed on the row (a failed action is marked in red). A second run should only appear later if the same incident worsens materially; it will not re-run on every polling cycle.

Troubleshooting

• Symptom: Trend Spike Detected doesn’t show up in the trigger picker. Fix: Your tenant doesn’t have the Trends beta flag on. Confirm with whoever manages beta access — the trigger and its merge tags are fully hidden until then, both in the manual builder and the AI builder.

• Symptom: The rule is enabled but never fires, and nothing on screen explains why. Fix: Same root cause as above — the trigger only actually runs for tenants with the flag on. A rule built before the flag was enabled, or for a tenant that never got it, will sit enabled and silent.

• Symptom: I turned the beta flag off and can no longer rename or disable my existing rule. Fix: This shouldn’t happen — editing or disabling an existing Trend Spike rule is allowed even without the flag; only creating a new rule (or moving an existing rule onto this trigger) requires it. If you hit a block on a simple rename, contact support with the rule ID.

• Symptom: My message shows a different count than I expected. Fix: Check which unit the tag you used is in. trend.observed counts customers on a label alert but conversations on a volume alert, while trend.windowTotal always counts conversations. Comparing the two, or dividing one by the other, will give you a number that means nothing — use trend.shareOfWindow for a share.

• Symptom: {{trend.customers}} or {{trend.conversations}} renders blank or as literal text. Fix: Neither tag exists. They were listed in an earlier version of this article by mistake. Use trend.observed and trend.windowTotal instead — see step 6 for what each one counts.

See also

• What are Automations?
• Create your first automation
• Trigger types reference