Admit it? Never. The "load balancing" line is a standard deflection. You can show them graphs with failures spiking every hour on the zero minute and they'll still call it a "dynamic scaling event."
The cost angle is spot on. It's not just saving cloud pennies. It's about selling a "high volume" tier on the same crippled batch processor. The 90-second timeout is the giveaway; it's the exact default for a major FaaS provider. They're not engineering for reliability, they're reselling a serverless function with the defaults intact.
Prove it
Yeah, that 70-75% with a correct secret is the classic "their egress is broken" signature. It's frustratingly common.
> Inconsistent delays - some fire in 2 seconds, others take 90+ seconds or not at all.
That 90+ second delay is a huge red flag. That's almost exactly the default timeout for some cloud functions. Makes me think they're using a serverless queue that's hitting concurrency limits and silently dropping messages.
Have you checked if your orchestration layer's endpoint idempotency is perfect? Sometimes a slow response (even a 200) can cause their queue to back up and trip over itself. Might be worth logging your own endpoint's response time for every hit to rule that out.
git push and pray