Event Intake Triage (Onboarding)

Event Intake Triage (Onboarding)

1. 01

   Inventory every event source the client's stack already emits

   List the product analytics SDK, billing system, form handler, and support desk separately, and note which ones can only fire a callback rather than a scheduled poll.

2. 02

   Map each event to the downstream action it is supposed to cause

   A signup event that should create a CRM contact and a Slack ping is two destinations, not one, and each destination needs its own failure owner.

3. 03

   Assign a stable unique key to every event type before the first delivery

   Deduplication depends on a key that survives retries, so use an order ID or session ID rather than a timestamp generated at send time.

4. 04

   Confirm the receiving endpoint can answer within the client's timeout window

   Slow acknowledgements are the most common cause of duplicate fan-out, because the sender retries while the first request is still open.

5. 05

   Document the retry and dead-letter behavior for each destination

   Write down how many attempts occur, the backoff interval, and where a permanently failed event lands so support can replay it by hand.

6. 06

   Set a baseline delivery count per event type for the first seven days

   Without a baseline, a silent drop looks identical to a quiet week, and the client will notice the gap before your team does.

7. 07

   Name one person on the agency side who owns alert triage

   Shared ownership across the delivery pod means nobody checks the channel at 6pm on a Friday, which is exactly when a payment webhook fails.