A cart-abandonment message that normally lands in two minutes shows up six hours later, after the sale already ended. The question that follows is always the same: did Customer.io go down? Almost never. What broke is the journey design underneath it, built for a normal Tuesday and never tested against the one day of the year that sends ten times the volume.
The bottleneck is rarely the vendor
We already covered why CRM segments need to be ready before Cyber Week starts: that is the content side of the problem. The infrastructure side is separate, and it shows up inside journeys that were never built with peak volume in mind. A trigger that looks fine in testing, sending to a few hundred customers a day, behaves differently at ten times that volume: any step that calls an external system in real time, instead of using data it already has, becomes the point where everything else waits.
What actually slows a send down
The most common failure is a journey step that makes a live API call before it can send: checking current inventory, pulling a real-time price, or querying a third-party system for a status. On a normal day, that call adds a delay measured in milliseconds. On Black Friday, with volume spiking at the same hour across the entire customer base, every one of those calls queues behind the one before it, and the delay compounds instead of staying constant.
The second common failure is overlap: more than one journey firing off the same event. A customer who abandons a cart on Black Friday might trigger an abandonment flow, a browse-abandonment flow, and a post-purchase flow within the same hour if none of those were built to check whether another one already fired. That is not a vendor limit, it is a design gap that only shows up once volume is high enough to expose it.
How to check before the day arrives
- List every journey that fires off a high-traffic event, cart abandonment and order confirmation first, and confirm none of them overlap with another journey on the same trigger.
- Find any step that makes a real-time external call. If the data behind it (inventory, price, status) can be cached or pre-computed instead of looked up live inside the send, move it out of the critical path before the event, not during it.
- Watch queue depth live during the event, not open rate or click rate after the fact. A message that sends successfully but arrives six hours late already missed the moment it was triggered for.
- Test the actual peak hour, not an average day. Black Friday load concentrates in a few hours, not spread evenly across the week; a test built on average daily volume misses the spike entirely.
None of this is a reason to avoid Customer.io on the busiest day of the year. It is a reason to treat journey design the way a team treats a checkout page before a sale: tested at the volume it will actually see.