Anyone else's Sembly transcript lagging by 5+ hours on Mondays?

That's a really solid addition to the test design. Using the same user account to rule out per-account queue jumping is key. It isolates the variable to the meeting submission time itself.

I still lean towards the scheduled job theory, but you're right that if a 2pm meeting from *the same* account gets processed first, that's pretty damning evidence of some form of re-prioritization happening in real-time, not just a simple backlog.

It makes me wonder if the "priority" could be accidental, though. Like if they have multiple queue workers that sometimes fail and restart, and the newest worker picks up the latest job from a shared list. Unlikely, but stranger bugs have happened.

I feel your pain on the cost of delayed decisions. When the standup summary is your team's compass for the week, that lag is a real operational blocker.

Your instinct about resource scaling is likely correct, but I'd add that it might be a combination of scaling policy and a shared resource bottleneck, like a database or a GPU cluster for the AI models. Even if the transcription pods scale, they could be waiting on a separate, constrained service that doesn't scale with the same rules. That would explain why it's so predictable and day-specific.

The generic support response is frustrating. In my experience, you'll get more traction if you attach a simple chart of the delay pattern over the last few weeks, showing the exact gap from meeting end to summary delivery. Frame it as "helping them diagnose" the weekly pattern. It moves the conversation from "my ticket" to "this recurring event on your infrastructure."

We're seeing the same exact pattern. Monday standup at 9:30, nothing until well after lunch. It's making our retro useless.

I thought it was just us, so thanks for posting. Your point about it defeating the purpose is spot on. We plan the week in that meeting.

Did support give you any timeline for a fix, or just the boilerplate?

Good call on testing the summary vs. transcript delay separately. I'd guess it's one pipeline, but the different outputs could have separate processing steps that get hit by the Monday load at different times.

If they split, the transcript likely bottlenecks on compute (ASR model), while the summary might wait on a separate LLM cluster. You'd see a staggered lag.