X Brand Mention Volume Spike Sentinel

A spike in public mentions of a product name, outage keyword, or incident hashtag is often the first signal something is wrong, well before a ticket lands in a support queue or a status page gets updated. X has no built-in alert for "mentions just spiked"; this blueprint runs the search itself on a schedule and turns the count into a Slack page the moment it crosses a threshold you set.

This blueprint was created by Mohit Jeswani.

How it works

1. search_mentions (io.kestra.plugin.xquik.tweets.Search) searches X for search_query within the last since_hours, capped at limit results. Read-only; nothing is posted or changed. allowFailure: true covers an API or auth error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) compares the returned size (a best-effort count of matching posts) against max_mention_count. A failed search is also CRITICAL.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs the count, below threshold.
   • alert: posts the count and search query to Slack.
4. summary logs the count and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an expired API key.

What you get

• An early warning the moment mention volume for a brand, product, or incident keyword crosses your own declared threshold, not a dashboard someone has to remember to check.
• A check that works the same for a brand name, a competitor, an outage hashtag, or a specific account via from:/to: operators.
• A full execution history of every check's count, so a slow build-up is visible, not just a single spike.

Who it's for

• Comms, PR, and social media teams who want a volume-based early warning before a public issue reaches official channels.
• SRE and support teams who want public mention volume treated as another signal alongside their own monitoring, for outages or incidents customers notice before an internal alert fires.
• Teams evaluating the Xquik plugin who want a worked example of tweets.Search used as a threshold-based governance check.

Why orchestrate this with Kestra

X surfaces the posts; it does not decide a cadence, compare the volume to a baseline you control, or notify a specific Slack channel. Kestra keeps max_mention_count and since_hours as flow inputs, turns a search into a Slack page naming the exact count, and keeps a full execution history of every check.

Prerequisites

• An Xquik API key (xquik.com) for searching X/Twitter.
• A search query that reliably returns some baseline volume, to tune max_mention_count against real traffic rather than guessing.
• A Slack incoming webhook URL.

This flow calls the Xquik API directly over HTTPS; there is no official local Xquik or X emulator, so search_mentions cannot be exercised against a local Docker container.

Secrets

• XQUIK_API_KEY: the Xquik API key used by search_mentions. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_XQUIK_API_KEY.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
search_query	<your-brand-or-keyword>	X search query to watch
query_type	Latest	Latest (chronological) or Top (engagement-ranked)
since_hours	1	Lookback window in hours
limit	100	Max posts requested; the reported count never exceeds this
max_mention_count	50	Mention count that triggers the Slack alert

Outputs

• {{ outputs.search_mentions.size }}: best-effort count of matching posts, capped at limit.
• {{ outputs.search_mentions.body }}: the raw search response.
• {{ outputs.evaluate.values.severity }}: OK, VOLUME_SPIKE, or CRITICAL.

Pitfalls

• size is capped at limit, not a true total match count. If the real mention volume exceeds limit, size reads exactly limit and you cannot tell "there were exactly this many" from "there were at least this many." Set limit well above max_mention_count so a genuine spike is distinguishable from a capped result.
• max_mention_count has no universal correct value; a brand with high everyday mention volume needs a much higher threshold than a niche product. Tune it against your own real traffic before enabling the schedule.
• sinceTime bounds the search window but this task does not paginate with cursor automatically; a very active query within a short since_hours window can still be capped by limit well before the window's true volume is reflected.

Quick start

1. Add the XQUIK_API_KEY and SLACK_WEBHOOK_URL secrets.
2. Run the flow manually with search_query set to something with known, real volume and read the count in summary.
3. Set max_mention_count below that observed count to confirm alert fires.
4. Restore max_mention_count to a value above your normal baseline.
5. Enable the hourly trigger once the threshold reflects real traffic, not a guess.

How to extend

• Run several copies of this flow side by side, one per brand, competitor, or incident keyword, each with its own threshold and Slack channel.
• Use from:/to: query operators to watch a specific account's mentions instead of a general keyword.
• Read outputs.search_mentions.body in a downstream task to extract and post the most engaged individual posts, not just the count.

Links

• Xquik plugin: https://kestra.io/plugins/plugin-xquik
• Xquik API documentation: https://xquik.com/
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks