Replay Failed HubSpot Webhooks Without Duplicate Records

Replay is where teams turn one incident into two

In my recent HubSpot and Make.com audits, the most expensive webhook failures were rarely the original timeout.

The real damage usually happened 15 to 90 minutes later, when someone tried to replay the failed event without checking what had already happened.

That is the dangerous pattern:

• the original webhook partially succeeded,
• HubSpot may already contain a new contact, owner change, or lifecycle update,
• Slack or another downstream tool may have failed,
• an operator reruns the whole branch,
• the second run writes duplicate business state.

That is why teams need to know how to replay failed HubSpot webhooks without duplicate records before incidents pile up.

One intake lane I reviewed had only 6 visible webhook incidents in a week. The hidden cost was larger: 4 of those incidents were replayed manually, and 3 of those manual reruns created second-order issues such as duplicate contacts, repeated owner alerts, or lifecycle history that no longer matched actual sales handling.

If your team already sees duplicate contacts, conflicting owner history, or confusing reruns in HubSpot-connected flows, start with Make.com error handling, use HubSpot workflow automation when lead routing is involved, and review the operating model on About. For published proof on this exact failure class, see the Typeform to HubSpot dedupe case.

What replay should mean in production

Replay should not mean "run the whole thing again."

Replay should mean:

1. identify the original business event,
2. confirm current state across HubSpot and connected systems,
3. replay only the missing safe step,
4. prevent already-completed side effects from firing again,
5. close the incident with evidence.

If your workflow cannot do that, it does not have replay. It only has rerun.

The three replay classes

Before touching the failed event, classify the incident into one of these three buckets.

Class 1: safe replay

Use this when:

• original event key is known,
• no write happened yet,
• state is clearly failed before first non-idempotent side effect,
• downstream systems confirm no object was created or changed.

This is the easiest class. Replay can usually continue on the normal write path with the same processing_id.

Class 2: targeted repair replay

Use this when:

• one side effect already completed,
• another side effect failed,
• current state is partially complete,
• business event must be repaired without rewriting finished steps.

This is the most common production case.

Example:

• HubSpot contact upsert completed,
• owner assignment completed,
• Slack notification failed,
• state stayed failed because the lane tracks whole-run outcome,
• operator must replay notification path only.

Class 3: unsafe replay

Use this label when:

• original event key is missing,
• current HubSpot state cannot be reconciled,
• multiple branches may already have written conflicting state,
• operator cannot tell which side effects already happened,
• rerun would create new ambiguity.

Do not replay this class automatically.

Escalate it into manual investigation with object-level reconciliation first.

Why HubSpot webhook replay creates duplicates so easily

HubSpot-connected webhook lanes fail in a specific way.

The event rarely stays inside one system.

A typical lane looks like this:

HubSpot webhook
  -> receiver or Make.com trigger
  -> payload normalization
  -> state lookup
  -> HubSpot search or upsert
  -> owner assignment or lifecycle update
  -> Slack / task / routing handoff
  -> completed-state write

If the lane fails after step 4 or 5, the webhook is no longer in a clean pre-write state.

That means a full rerun can cause:

• second contact create attempt,
• second owner assignment,
• repeated lifecycle movement,
• duplicate Slack alerts,
• false incident evidence because timestamps now overlap.

This is the same failure pattern behind Webhook retry logic: stop duplicate CRM and finance writes and HubSpot sends multiple webhooks: how to deduplicate in Make.com.

The evidence you need before replay

Do not replay from emotion or urgency.

Collect five facts first:

1. Original event identity

You need one stable key such as:

• webhook eventId,
• source object ID plus occurred timestamp,
• submission token,
• deterministic processing_id already stored in state.

If the replay uses a new key, you are not replaying. You are creating a second business event from the same incident.

2. Current workflow state

Confirm the most recent persisted state:

• received,
• processing,
• completed,
• failed,
• quarantined,
• or branch-level partial status.

If state says completed, a full replay is usually the wrong move.

3. Current HubSpot object truth

Check the actual object before you rerun anything:

• does the contact already exist,
• did owner assignment already happen,
• did lifecycle stage already change,
• were associated tasks or notes already created,
• did another workflow mutate the same record after the incident.

HubSpot UI alone is sometimes not enough. Use object history or API evidence when needed.

4. Downstream side-effect truth

Confirm whether Slack, task creation, routing queue, or another system already received the event.

If downstream side effect succeeded once, replay should not send it again unless your policy explicitly allows repeat delivery.

5. Failure reason class

Classify the failure before replaying:

• timeout after unknown write result,
• validation failure,
• rate limit,
• branch error after CRM write,
• missing required field,
• operator interruption,
• queue backlog or concurrency issue.

Replay strategy depends on failure class. A validation failure should usually not rerun until input is corrected. A transient downstream timeout may be safe for targeted repair.

The six replay gates that prevent duplicate records

Use these as strict gates, not suggestions.

1. Same event key, never a fresh one

Replay must reuse the original processing_id or event key.

Allowed:

• replay original event hs_event_98182,
• repair original processing_id=lead_4471_submit_20260308T0811.

Not allowed:

• generate new execution timestamp,
• hash a new payload variant,
• rerun from module history with a new synthetic key.

This is the first gate because every other dedupe check depends on durable identity.

2. Replay only from persisted state

Do not infer replay position from memory or from one screenshot of run history.

Replay should start from persisted branch state such as:

replay_state:
  processing_id: lead_4471_submit_20260308T0811
  hubspot_object_id: 12837721
  status: failed
  branch_status:
    upsert_contact: completed
    assign_owner: completed
    send_slack: failed
    write_summary: pending
  failure_class: downstream_timeout
  owner: revops

When state is explicit, replay knows what to skip and what to repair.

3. Treat CRM writes and notifications as separate side effects

Teams often replay whole branches because they model the lane as one execution instead of multiple side effects.

Split at least these side effects:

• contact create or update,
• owner write,
• lifecycle change,
• deal association,
• Slack or email alert,
• audit-log or summary write.

Each side effect needs its own completion marker or skip condition.

If you treat everything as one block, every replay is more dangerous than it needs to be.

4. Reconcile HubSpot before replaying downstream

If HubSpot already contains the intended state, do not rerun the HubSpot write just because Slack or another handoff failed.

This is where teams accidentally create duplicates.

Correct sequence:

1. inspect current HubSpot object,
2. compare it to intended state,
3. mark CRM step as completed if truth already matches,
4. replay only the missing downstream step.

This repair-first sequence is also why HubSpot workflow audit: 7 silent failures should sit next to replay runbooks.

5. Block replay on validation failures until input is fixed

If the webhook failed because required fields were missing, replaying immediately is usually pointless or harmful.

Examples:

• owner cannot be assigned because territory is blank,
• lifecycle update depends on missing segment,
• merge policy check failed on conflicting identity.

In these cases, the correct path is:

• correct input,
• record reason code,
• replay with same key after validation passes.

This overlaps directly with HubSpot required fields before AI enrichment.

6. Every replay needs owner, reason code, and close evidence

Operationally, replay is an incident action.

Minimum metadata:

• who approved replay,
• why replay was needed,
• which branch was replayed,
• what was skipped because it was already done,
• what evidence confirmed success.

If the lane has no owner or no close evidence, replay quality will degrade within weeks.

Copy-paste replay contract

Use a small contract per replayable event:

replay_contract:
  processing_id: hubspot_contact_12837721_event_98182
  source_event_id: 98182
  object_type: contact
  object_id: 12837721
  overall_state: failed | partial | completed | quarantined
  side_effects:
    contact_upsert: completed
    owner_assignment: completed
    lifecycle_transition: skipped
    slack_notify: failed
    audit_summary: pending
  replay_mode: none | targeted_repair | safe_reprocess | manual_investigation
  failure_class: timeout_after_downstream_success
  approved_by: revops_owner
  last_replayed_at: 2026-03-08T09:20:00Z
  evidence:
    hubspot_checked: true
    downstream_checked: true
    duplicate_blocked: true

This is intentionally small.

If your replay contract needs ten screens of hidden logic, operators will bypass it during incidents.

Safe replay sequence for HubSpot-connected flows

Use this sequence when the failure is real and time matters.

Step 1: freeze blind retries

If automatic retries or operator reruns are still possible, stop them first.

You need one incident owner, one investigation path, and one replay decision.

Step 2: inspect current business truth

Confirm the current state in HubSpot and every system that matters for the lane.

Minimum checks:

• object exists or not,
• owner is correct or not,
• lifecycle state is correct or not,
• notification already sent or not,
• follow-up task exists or not.

Step 3: compare intended outcome to current truth

If the business truth already matches intended outcome, do not rerun the original write.

Mark completed steps as completed and move to the missing side effect only.

Step 4: choose one replay mode

Use one of these modes only:

• targeted_repair for one failed downstream step,
• safe_reprocess only when no side effect completed,
• manual_investigation when truth is ambiguous.

Do not invent a new replay mode in the middle of an incident.

Step 5: replay the missing branch with the original key

This branch should:

• read the original processing_id,
• skip already-completed side effects,
• execute only the missing safe step,
• update state immediately after success.

Step 6: write close evidence

Close evidence should answer in under two minutes:

• what failed,
• what was replayed,
• what was skipped,
• why duplicate records were prevented,
• who owns future follow-up.

What not to replay

Some failures should not be replayed until you change design or data.

Do not replay blindly when:

• source identity is ambiguous,
• two HubSpot records may already exist for the same event,
• failure came from bad input that is still bad,
• replay would overwrite a manual operator correction,
• lifecycle state changed after the original incident,
• round-robin owner logic would consume a second slot,
• the lane has no state ledger and no object history.

In those situations, repair data first and then decide whether any replay is still necessary.

A 10-day hardening plan for teams that already got burned

Days 1-2

• inventory all replay points in the lane,
• mark which side effects are write-once versus replayable,
• identify where operators currently rerun from history or UI.

Days 3-4

• define stable processing_id strategy,
• persist side-effect status per event,
• separate completed from partial and failed.

Days 5-6

• add targeted repair branch,
• add skip logic for completed CRM writes,
• add replay approval metadata.

Days 7-8

• simulate timeout after HubSpot success,
• simulate Slack or queue failure after owner assignment,
• verify duplicate-prevented evidence for each test.

Days 9-10

• hand off replay runbook,
• add daily review of failed and partial states,
• align the delivery and ownership model with How It Works.

If the team needs a faster production fix, start with Contact or use the free reliability checklist before touching another high-risk lane.

The practical rule

You should replay business intent, not scenario execution.

That means one event key, explicit side-effect state, and a repair path that knows what already happened.

If your current method is "open history and click rerun," you do not have replay control yet.

Next steps

If this is already a live issue in HubSpot-connected automations:

• review the service scope: Make.com error handling
• review the commercial HubSpot lane: HubSpot workflow automation
• compare with production proof: Typeform to HubSpot dedupe
• align replay with state design: Make.com Data Store as a state machine
• review upstream duplicate causes: Typeform, HubSpot, Slack: where duplicate writes start
• if you want a paid audit, go straight to Contact

FAQ

Can I replay a failed HubSpot webhook from Make.com history if I add dedupe later?

Usually not safely for the old incidents. New dedupe logic helps future events, but past ambiguous incidents still need object-level reconciliation before replay because the original side effects may already exist.

Should replay always skip HubSpot if the contact already exists?

Not automatically. It should skip only the side effect that already matches intended truth. If the contact exists but owner assignment or lifecycle state is still wrong, replay can still repair those missing steps with the original key.

What is the minimum state I need to store for safe replay?

At minimum: original event key, current overall state, branch-level side-effect status, failure class, last update time, and owner. Without that, replay decisions depend too much on manual memory.

Can HubSpot alone handle this without external state?

Only for very simple lanes. Once the webhook touches Make.com, Slack, enrichment, routing, or other downstream systems, you usually need explicit external state and targeted repair logic to prevent duplicate records during replay.