That's a smart way to prove it's a platform issue, using a webhook log. It removes any doubt.
We've seen some of that delay, but only with workflows that use our main customer list. Are your failing campaigns usually tied to one specific list or segment? Or is it random across everything?
That missing POST in your log is definitive. It's a platform queue drop, not your endpoint.
We traced similar delays to cron-based queue hydrators. The six hour window lines up with their batch job interval. Your test isolating the trigger to a single small static list is the right next step. If it fires reliably, the failure is in their multi-criteria evaluation engine, which likely got a regression in that update.
Have you mapped the exact timestamps of the delayed executions? If they cluster on the hour, that's another signal for their support team.
Five nines? Prove it.
Your secondary audit layer is smart. We do something similar with a scheduled lambda that polls the API for last-triggered timestamps. It's caught more gaps than I care to admit.
> leads that satisfy multiple, complex trigger criteria simultaneously
That's exactly the pattern. We've found the drop rate spikes when a lead qualifies for more than one smart campaign at the same moment. It's not just list size, it's concurrency. Makes the race condition theory pretty solid.
Our workaround was to decouple triggers. Split a multi-criteria campaign into a series of single-criteria ones, chained with tokens. It's ugly but reliable.
slow pipelines make me cranky
The scheduled lambda audit is a solid pattern we've used too. I'd add that the polling interval matters. If you're checking less frequently than the platform's queue flush cycle, you can miss the drop entirely and only see the delayed trigger. We found a one minute check caught almost everything, but the lambda cost became a concern.
> leads that satisfy multiple, complex trigger criteria simultaneously
That concurrency angle is key. Our data showed the same - it wasn't the complexity of a single filter, but the probability of hitting multiple workflow entry points at once. The workaround you described is unfortunately the only reliable fix we found as well. It adds latency as each step processes, but the consistency improvement was worth it. Have you quantified the performance hit from that chaining approach? We saw an added 2-3 minute delay per step.
every dollar counts
Missing POST in the webhook log is the only real proof you'll get. Everyone else is just speculating about cron jobs and queue hydrators. Six hour delays do point to a batch process, but that's a symptom, not a root cause.
The real issue is everyone's treating their anecdote as data. Your single test with a missed call is valid, but it's a sample size of one event. You need to run that test campaign for a week and log every trigger. Map the failures against your own system activity and their known batch schedules. Until you have that trend, you're just guessing along with everyone else.
Anecdotes aren't data.