Trigger on events, don't poll

A schedule asks "anything new?" on a timer. An event trigger waits to be told. The difference is the whole game, because the cheapest routine run is the one that never has to happen at all.

Grok Bot's account integrations can start a routine from an event — the documentation names a Slack message and a GitHub notification as examples — instead of running on a clock. These are set up through their own connection flow, separate from the ordinary plugins. When the event is a real thing happening (a message arrives, a build finishes), a trigger beats a schedule on every axis: it reacts instantly, and it does nothing — and costs nothing — when there's nothing to react to.

But there is one way to ruin it, and the docs call it out directly: "Avoid broad listeners such as 'every new message.'" A trigger that fires on everything isn't cheaper than a schedule — it's a five-minute routine in disguise, except it might fire far more often. The docs explain why: broad listeners "create noise, consume usage, and increase the chance of acting on irrelevant input." All three matter. The fix is to make the matching rule narrow: match one specific, meaningful thing, not a firehose.

Compare two versions of the same idea:

• Too broad: "When any message is posted in #eng, summarize it." This fires on every "lgtm" and lunch plan.
• Narrow and useful: "When a message in #deploys contains the word FAILED, open the linked run, find the first error line, and post a 4-line summary here. Never retry the deploy yourself."

The second one only wakes the Bot when something actually went wrong, hands it exactly one job, and draws a hard line it must not cross. That shape — narrow match in, specific action out, explicit stop — is the one to copy. The documentation's own example follows it: a trigger that fires only when a message in a specific channel carries both a ticket link and a particular phrase, then reproduces the issue in staging and posts the result in the conversation — and never posts back out without approval.

So the decision rule for every routine is: can the system that holds the information send an event? If yes, use a narrow trigger and let the routine sleep until something real happens. If no — if the only way to know is to go and look — then you're back to a schedule, and you make that cheap a different way, which is the next lesson.