Gorgias Auto-Reply Loop & Auto-Close Misfires: How to Stop Them

Symptom to likely cause, at a glance

Start here, then jump to the matching section below.

1. The loop: your rule re-fires on every message

Most common cause of the loop: the rule triggers on "New Message In Ticket" and has no guard against replies. When you build an auto-reply that fires on a new message rather than only on ticket created, Gorgias re-evaluates that rule every single time a message lands on the ticket — including your own agents' replies and the customer's follow-ups. Each qualifying message fires the auto-reply again, and you get the stack of duplicate canned responses.

The fix is one condition. Add Message From Agent Is False to the rule. Per Gorgias's Rules FAQs, this is the condition that stops the rule activating when a team member responds — so an agent's reply no longer counts as a fresh trigger, and the loop breaks. If you specifically want the auto-reply to acknowledge only the customer's first inbound message, trigger the rule on Ticket Created instead of New Message In Ticket; that event only happens once per ticket, so it can't loop by definition.

There's also a safety net you don't have to configure. Gorgias throttles duplicate auto-replies on its own: as the Rules FAQs put it, "we don't send a single auto-reply more than once per 5 min per customer, to avoid spamming customers with the same message over and over again." That 5-minute per-customer window is why a loop sometimes looks intermittent — rapid-fire messages get collapsed, but a thread that spans hours will still re-fire on each new message unless you add the from-agent guard. Don't rely on the throttle as your fix; it's a backstop, not the cure. The cure is Message From Agent Is False (and picking the right trigger event). For a fuller tour of how the WHEN / IF / THEN structure works, see Gorgias rules explained.

2. Two auto-replies fire on one ticket

Cause: more than one rule matches the same message. If you've built several auto-reply rules over time — one for order status, one for returns, one for "we're closed" — and their conditions overlap, a single inbound email can satisfy two of them and send two replies. Because rules of the same trigger type run top to bottom, both fire unless one is scoped tightly enough to exclude the other.

The fix: consolidate and scope. Audit your active auto-reply rules and make their conditions mutually exclusive (tags, ticket channel, or keyword conditions that can't both be true), or fold them into a single rule with branching. The 5-minute throttle will suppress an identical duplicate, but two different auto-replies aren't identical, so the throttle won't save you here — the scoping has to. When you're building or editing these, how to set up rules in Gorgias walks through the condition builder step by step.

3. Auto-close is closing real tickets

Cause: the auto-close rule is matching too broadly, or the wrong addresses aren't excluded. Gorgias ships an Auto-close spam emails rule as a managed automation — per the Auto-close Spam emails doc it can't be freely modified or duplicated like an ordinary rule. What you can tune is its Email exclusion list (addresses or domains it should never touch) and its Always apply list (addresses it should always close). When a genuine sender — a supplier, a marketplace notification you actually read, a VIP customer on an unusual domain — keeps getting swept up, the fix is to add them to the exclusion list rather than disabling auto-close wholesale.

The rule detail is also where you can sanity-check the blast radius before you trust it. The Affected tickets preview shows a live sample of tickets the rule is closing, so you can eyeball whether anything legitimate is in there.

4. Auto-close runs at the wrong time (rule order)

Cause: auto-close sits below auto-reply, so the auto-reply fires first. Gorgias evaluates rules in a defined priority — per Rules 101, the trigger order is Ticket created, then New message in ticket, then Ticket updated, then Ticket assigned to user — and when two rules share the same trigger type, they run in the order they appear on the rules page, top to bottom. If your auto-close and your auto-reply both trigger on "Ticket Created" but auto-reply is listed higher, a spam ticket gets an auto-reply before auto-close ever closes it. Now you've replied to a spammer.

The fix: keep the auto-close rule above the auto-reply rule, on the same event. This is exactly what the rule detail's own callout tells you — "keep this rule at the top of your rules to ensure it triggers first." Put auto-close first and use the same first-line event on both rules (either Ticket Created or New Message In Ticket, or both), so the close wins the race and the auto-reply never touches a ticket that's already been binned as spam.

The honest limit: rules match patterns, not meaning

None of the above is a Gorgias defect — the rule engine is deterministic and, once you know the trigger order and the from-agent guard, entirely predictable. That predictability is the point: a rule either matched or it didn't. But it's also the ceiling. Auto-reply and auto-close both decide by pattern — sender, keyword, tag, channel — and they can't tell that "where's my stuff" and "I never got my order, this is the third time I'm writing" are the same intent with different heat, or that a "spam-looking" address is actually a frustrated repeat customer. So you end up hand-maintaining exclusion lists and keyword conditions, and those are exactly the things that quietly break when wording shifts. If your loops and misfires keep coming back because real customer language keeps escaping your conditions, you've hit the edge of what rules can express.

Where an AI layer picks up

This is the seam where an AI agent layer helps. The broader category of AI agents for customer service exists to act on intent rather than exact keywords — so a genuine question gets answered and true junk gets closed, without a hand-ranked stack of rules to keep in sync. Macha is one such layer, and it's honest about what it is: it runs on top of the Gorgias you already use, not instead of it. It connects to your helpdesk and reads and writes the same tickets your rules touch — replies, tags, status, assignment — so your deterministic rules keep doing the routing they're good at while the agent handles the intent-heavy work they were never built for. If you'd rather see the mechanics first, Gorgias AI agent explained and connecting Gorgias to Macha to automate ticket replies cover the connection and what it can do.

Because an agent acts on meaning, you don't just enable it and hope. Macha lets you batch-grade a candidate agent against your real historical Gorgias tickets before it touches a live queue, and you can extend it with a custom tool that turns any REST API into an action — looking up order status mid-conversation, something no native rule condition can do. Credits are charged per AI action, not per resolution; the pricing page has the specifics.

FAQ

Why does my Gorgias auto-reply fire on every message instead of just once? Because the rule triggers on New Message In Ticket, and Gorgias re-evaluates it on every new message — including your agents' replies. Add the condition Message From Agent Is False so agent responses don't re-trigger it, or trigger the rule on Ticket Created (which happens only once per ticket) if you only want to acknowledge the customer's first message.

How often can the same auto-reply be sent to one customer? Gorgias throttles it: per its Rules FAQs, "we don't send a single auto-reply more than once per 5 min per customer." That's a backstop against spamming, not a substitute for the "Message From Agent Is False" condition — a thread spanning hours will still loop without the guard.

How do I stop auto-close from closing real customer tickets? Add the sender's address or domain to the auto-close rule's Email exclusion list so it's never swept up, and use the Affected tickets preview to check what the rule is actually closing before you trust it. The Auto-close spam emails rule is a managed automation, so you tune it through its exclusion and "always apply" lists rather than rewriting its logic.

Should auto-close be above or below my auto-reply rule? Above. Keep the auto-close rule at the top and give both rules the same first-line event (Ticket Created and/or New Message In Ticket), so spam is closed before the auto-reply can respond to it. Rules of the same trigger type run top to bottom.

Can AI replace these rules entirely? Not necessarily — and it doesn't have to. An AI agent layer like Macha connects on top of Gorgias and acts on intent, so it can answer real questions and close true junk without a hand-ranked rule stack, while your deterministic rules keep handling routing. See connecting Gorgias to Macha for how the layering works.

Tired of babysitting rule order and exclusion lists? Start a free trial and grade a Macha agent against your own Gorgias history before it ever touches a live ticket.