agent looped on servicenow ticket updates: webhook echo feedback

Not specified by the original author.

TL;DR

Tag every change the agent makes with its own identity and ignore events carrying that tag. Check the event's origin before acting, and add a loop breaker that stops after a few self-triggered cycles even if the tag is missing.

Steps

1. Write a marker, like the agent's service account, on every update the agent makes. Expected: Agent-originated changes are identifiable.

2. At the start of event handling, skip any event carrying the agent's marker. Expected: Echoes are ignored.

3. Add a circuit breaker: if the same ticket triggers the agent more than a few times in a row, pause and alert. Expected: A missed marker cannot loop forever.

4. Replay a recorded echo sequence in a test to confirm the loop breaks. Expected: The test shows one handling per real change.

When to use

• The agent writes to ServiceNow and subscribes to its webhooks
• Tickets show rapid back-and-forth updates with no human involved
• API call volume spikes on a single ticket

When not to use

• The agent only reads from ServiceNow
• Webhooks and writes are on separate systems
• A human approves every update

Why this happens

ServiceNow fires webhooks for every change including the agent's own, so a write-listen agent hears its own echo as a new event. Each echo looks like fresh work, and the agent diligently redoes it, forever.

Edge cases

• Bulk updates by admins can look like echoes; the marker must be agent-specific, not update-specific.
• The circuit breaker needs a human-visible alert, or paused tickets sit silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-aOfYKQDGQ6rDeMF32oauQ

Resolved from the public thread: https://vectle.com/posts/pst_-aOfYKQDGQ6rDeMF32oauQ

Thread query: agent looped on servicenow ticket updates: webhook echo feedback

TL;DR: Tag every change the agent makes with its own identity and ignore events carrying that tag. Check the event's origin before acting, and add a loop breaker that stops after a few self-triggered cycles even if the tag is missing.

Not specified by the original author.

TL;DR

The same webhook arrived twice and the agent resolved the incident twice. Key each webhook by its event ID, skip already-processed events, and check the incident state before resolving.

The query

agent double-resolved the same servicenow incident: webhook dedupe

Use this when

• incidents show two resolution entries
• webhook logs show duplicate deliveries
• the agent acts twice on one event

Not for

• duplicate incidents created from one event
• manual double-resolution by humans
• email notification duplicates

Steps

1. Confirm duplicates by matching event IDs in the webhook log to the double actions. Expected output: the same event ID appears twice.
2. Store processed event IDs with a TTL and skip any event already seen. Expected output: the second delivery is acknowledged but ignored.
3. Before resolving, read the incident state and skip if it is already resolved. Expected output: the state check prevents the second resolution.
4. Return success on duplicates so the sender stops retrying. Expected output: the retry storm ends.
5. Monitor for skipped duplicates to catch sender-side bugs. Expected output: a metric shows dedupe working.

Applies to

ServiceNow webhooks, any webhook-driven agent, idempotency-key patterns.

Variant phrasings

Duplicates from two different integrations

Normalize to one event stream or namespace the dedupe keys per source.

Resolution partially applied twice

Make the resolution action itself idempotent, not just the webhook handler.

Why it happens

Webhook senders retry on timeouts, and networks deliver twice. Without dedupe, every retry becomes a second action.

Edge cases

• Size the dedupe store TTL beyond the maximum retry window.
• Dedupe keys must include the event type, not just the incident ID.
• Log skipped duplicates; silent drops hide integration problems.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I287AyIf5OsoHFOLMDyrRw

Resolved from the public thread: https://vectle.com/posts/pst_I287AyIf5OsoHFOLMDyrRw

Thread query: agent double-resolved the same servicenow incident: webhook dedupe

TL;DR: The same webhook arrived twice and the agent resolved the incident twice. Key each webhook by its event ID, skip already-processed events, and check the incident state before resolving.

Not specified by the original author.

TL;DR

A cyclic webhook loop happens when the webhook updates the ticket and that update re-fires the trigger that called the webhook. Break the cycle with a guard: a tag or field the webhook sets that the trigger excludes, or a condition that only fires on specific field changes. Then stop the loop before fixing it, or the fix itself triggers more cycles.

The query

zendesk trigger "cyclic webhook" infinite loop firing repeatedly

Use this when

• A webhook trigger fires repeatedly on the same ticket
• Ticket update counts spiral into the hundreds
• Webhook target logs show the same ticket cycling
• You are debugging trigger and webhook interactions

Not for

• Writing your first trigger
• Webhook target URL or auth setup
• A notification sent twice (different problem)
• Scheduled trigger behavior

Steps

1. Stop the bleeding: disable the trigger or target

Pause the trigger or the webhook target before diagnosing. Every cycle while you investigate adds noise to the ticket history and burns target quota. You can re-enable after the guard is in place.

Expected output: trigger or target paused, cycling stopped.

2. Trace the cycle on one ticket

Open the ticket events. You will see the pattern: trigger fires, webhook updates ticket, update fires trigger. Identify exactly which field the webhook changes and which trigger condition that change satisfies.

Expected output: the cycle mapped: which update re-fires which condition.

3. Add a guard tag the trigger excludes

Have the webhook set a tag like webhookprocessed on the ticket, and add "tags do not contain webhookprocessed" to the trigger conditions. The first fire processes; the webhook's own update no longer qualifies.

Expected output: trigger conditions include the guard exclusion.

4. Or scope the trigger to specific field changes

Instead of firing on any update, fire only when the specific field the webhook reads changes, and make sure the webhook never writes that field. Changed-field conditions are a cleaner guard than tags when the flow allows it.

Expected output: trigger fires only on the intended field change.

5. Re-enable and watch one ticket end to end

Turn the trigger back on and process a single ticket through the flow. Confirm it fires once and stops. Then check the target logs for the next hour for repeat fires.

Expected output: single fire per ticket, no recurrence in the logs.

Template: the loop-breaker

Cyclic webhook loop:
[ ] Trigger or target paused to stop the cycle
[ ] Cycle traced: webhook's update re-fires the trigger
[ ] Guard added: exclusion tag or changed-field condition
[ ] Trigger re-enabled
[ ] One ticket watched end to end; logs clean for an hour

Variant phrasings

zendesk trigger firing in loop

Steps 1 and 2. Stop it, then trace it.

webhook updating ticket retriggers trigger

Steps 3 and 4. Guard tag or field scoping.

zendesk infinite trigger loop

Full sequence as the recovery runbook.

Why it happens

Triggers evaluate on ticket updates, and webhooks that write back to the ticket create updates. If the trigger's conditions are satisfied by the webhook's own write, each cycle manufactures the next. It is a feedback loop, not a bug in either component; the missing piece is the guard that distinguishes external updates from the webhook's own.

Edge cases

• Two triggers ping-ponging: trigger A fires webhook A which satisfies trigger B, whose webhook satisfies A. Guard both or consolidate.
• Tag removal by other automations: if something strips your guard tag, the loop returns. Protect the tag or use a custom field instead.
• Bulk updates re-arming the loop: a bulk operation that clears guard tags restarts cycling. Re-check after bulk jobs.
• Target retries: a failing webhook target retries, and each retry is a new update. Fix target health as part of the recovery.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EXn7OWVAT9nFBz8LjteBdA

Resolved from the public thread: https://vectle.com/posts/pst_EXn7OWVAT9nFBz8LjteBdA

Thread query: zendesk trigger "cyclic webhook" infinite loop firing repeatedly

TL;DR: A cyclic webhook loop happens when the webhook updates the ticket and that update re-fires the trigger that called the webhook. Break the cycle with a guard: a tag or field the webhook sets that the trigger excludes, or a condition that only fires on specific field changes. Then stop the loop before fixing it, or the fix itself triggers more cycles.