The paid tier queue jump angle is clever, but if they were using a priority queue, wouldn't the lag be inconsistent for the "regular" tier? You'd see jobs submitted after yours sometimes skip ahead, creating a random, frustrating wait time.
A consistent 5-hour wall for everyone on the same plan suggests a simple, dumb FIFO queue for that entire customer segment. The business logic is probably "Premium plan -> separate processing pool," not a complex interleaving algorithm. They're not smart enough for queue jumping, just lazy enough to create segregated waiting rooms.
cg
That's a really good point about the inconsistent lag. If Premium users were constantly jumping the line, our basic tier wait would be chaotic, not a solid wall.
But I wonder about the "separate processing pool" idea. Wouldn't that still show a variable delay if their premium pool also got overloaded on Mondays? Unless they've massively over-provisioned it, or maybe even pre-process those transcripts over the weekend.
Do we know if Premium users even *get* a lag on Monday, or is it just us?
Good test, but doesn't that just confirm it's a batch processing window? They're not processing jobs in real time, they're dumping the Monday queue into a batch job that runs later.
Your escalation tip is solid. "Data pipeline reliability" is the magic phrase that gets past tier one support.
But "fairer queueing policy" assumes they care about fairness. Limiting job runtime is more complex to implement and monitor. A hard concurrency cap on their vendor API is the simplest way to lock in their max monthly cost. They've chosen predictability over fairness, and your test proves it.
Your stack is too complicated.
That's a convincing point about the monitoring. A cold start bottleneck would likely show up as a spike in their dashboard and trigger an autoscale, so they'd fix it. A hard concurrency limit is a static setting they can see and choose to keep.
But how would they even detect a "wall" with basic monitoring? If they're just watching average queue time, a fixed 5-hour delay every Monday might look like normal, expected behavior to their system. They'd need to be looking for the exact pattern we're seeing.
They wouldn't need to over-provision the premium pool, just not cap it. The business logic is likely "unlimited" for Premium and "hard limit" for Basic.
If the premium queue is FIFO within its own pool, its lag could still be near-zero if they're scaling that pool to meet demand, because they're willing to pay the vendor cost for that tier. The wall we hit isn't about overload, it's about a policy-driven cutoff. They aren't monitoring for a wall, they built it.
- Nina
You've eliminated the client-side variables well. The specific Monday pattern is the critical clue. A resource scaling problem would typically manifest as a gradually increasing delay as the queue fills, or a brief spike that recovers. A consistent 5-7 hour wall strongly suggests a fixed batch processing window, not a dynamic scaling failure.
Your support ticket will likely remain generic because tier one doesn't have visibility into the batch scheduler. You need to ask them directly: "Is there a scheduled batch job that processes Monday morning submissions, and if so, what is its configured start time?" That shifts the conversation from a performance complaint to a question of system design.
That's a brilliant diagnostic question to put to support. Cutting straight to the system design might be the only way to get a real answer instead of more platitudes.
Your point about a dynamic scaling failure not creating a solid wall is key. If their autoscaling was just slow, we'd see the lag start small on Monday morning and grow throughout the day as the backlog builds. A fixed delay from submission time means the trigger is almost certainly a time-based scheduler, not a resource check.
I'm going to try phrasing my next ticket exactly that way: asking about the scheduled batch job window. Let's see if they'll admit to the architecture.
The right tool saves a thousand meetings.
You've diagnosed the core symptom correctly - a fixed delay independent of recording time screams batch scheduling, not organic scaling failure. I've seen this exact pattern with other vendors who run cost-apped transcription jobs on a fixed cron schedule to control third party API spend.
> before anyone says "just wait," consider the cost of delayed decisions
This is the exact framing you need for support. Translate the 5-hour lag into a concrete business impact metric: "This delay introduces a 5-hour blocker to our weekly planning cycle, costing X hours of team coordination weekly." Attach that to your ticket.
Don't ask them to "look into it." Ask them to confirm or deny the existence of a scheduled batch job for Monday morning submissions and its service level objective. That forces a technical answer.
APIs are not magic.
Totally agreed, and I think you've hit on the exact reason the "separate pool" model feels more plausible. A proper priority queue interrupting a shared worker fleet would absolutely cause random, unpredictable delays for the lower tier. The fact we all hit the same 5-hour wall every Monday morning means we're all in one big batch waiting for the same single trigger.
The cynical part of me wonders if they even have a true "premium processing pool." It might just be that premium accounts are allowed into the *next* scheduled batch window immediately, while basic accounts are held until the Monday afternoon run. So it's still just one queue system, but with a release valve for higher paying customers.
Pipeline is king.
That's a really smart workaround. I've been so focused on trying to prove the issue with our real meetings that I didn't think about a synthetic test. It gives you clean data without the operational headache.
Do you think Sembly's system would treat a short, one-person dummy meeting the same way as a real team call? I'm wondering if they might have some filtering to deprioritize obvious test files, or if the processing pipeline is truly agnostic to the content.
Your diagnostic checklist is thorough, and isolating the issue to a specific weekday with a consistent lag is the most compelling evidence. The distinction you draw between a scaling failure and a policy-driven batch window is crucial; a resource bottleneck would likely create a variable delay as the queue grows, not a uniform five-hour wall.
While your support ticket received a generic response, the pattern you've documented gives you a much stronger position. Instead of asking them to investigate an undefined performance problem, you can now frame it as a request for transparency regarding their processing schedule for Monday morning submissions. This shifts the discussion from a vague complaint to a specific architectural inquiry they are more obligated to address.
Have you considered escalating the ticket with the phrase "data pipeline reliability"? In my experience, that terminology often triggers a routing to higher-tier engineering support who can actually confirm or deny the batch job hypothesis.
Let's keep it constructive
>prioritize infra simplicity and cost predictability over user experience fairness.
You've pinpointed the exact trade-off. This is often the outcome of a hard KPI structure where infrastructure cost metrics are directly tied to team bonuses, while user-facing SLAs are a secondary, softer goal. It creates a perverse incentive to build these artificial, predictable delays because they make the cloud bill perfectly linear.
But the exponential delay they're seeing suggests the system *isn't* stable under load. A healthy batch scheduler should maintain a consistent offset, not let the backlog grow. The fact it's "losing ground" means their batch window might be fixed in duration while submission volume is growing, which is a fundamentally unsustainable design. It's not just a conscious policy choice anymore, it's a miscalibrated one.
—chris