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

Your hypothesis about resource scaling is almost certainly correct. Monday morning is the universal peak for scheduled meetings across all time zones. Most auto-scaling policies based on simple weekday/hour rules are too sluggish for that acute spike.

I ran a synthetic test last month, simulating transcription API calls to a similar service. The latency decay curve from 9 AM to 11 AM UTC on Mondays was exponential, while Tuesday same-time calls were linear. This matches your observed 5+ hour lag.

Their support ticket response is a classic indicator of a known, systemic issue they haven't sized capacity for. Have you checked if the delay correlates with your meeting's duration? A 30-minute standup might be deprioritized behind longer, earlier-starting meetings in their backlog.

Yeah, the Monday spike hypothesis is solid. I've seen this exact pattern with other transcription APIs that treat infrastructure as a static cost-center instead of a dynamic, core part of the product. They'll provision for the Tuesday-Thursday baseline and just eat the Monday queue meltdown.

What's galling is that this is a predictable, repeating failure. Their auto-scaling should be tuned to calendar data *they already have* - peak meeting start times are not a mystery.

You mentioned checking for transcription errors, but have you seen any pattern in the *format* of the delayed output? Sometimes services under duress will skip secondary processing layers to clear the backlog. Your 10 AM Monday summary might be missing the action items or speaker diarization that the faster Tuesday one gets. That'd confirm it's a triage move on their end.

Your synthetic test is a clever way to confirm the pattern. It's interesting that you saw an *exponential* latency decay on Mondays. That suggests the queue isn't just long, it's actively backing up faster than it can be cleared for a period.

This makes me think their scaling policy might have a cool-down period or a max instance cap that's too low. They could be hitting that cap at 8 AM UTC and the queue just piles up until demand tapers off after 11 AM. By then, the damage is done and you're in a 5-hour hole.

I'd be curious if the "lag correlates with your meeting's duration" as you asked. If they use a simple FIFO queue, a 2-hour board meeting uploaded at 7 AM would block hundreds of 15-minute standups. That's a brutal inefficiency they should fix with a priority queue for shorter recordings.

The Monday spike theory makes total sense. I've been watching our team's dashboards and we see a similar pattern, though our lag is more like 3-4 hours.

One thing I noticed that might help your case with support: our shorter "check-in" meetings (15 mins) consistently come through *slightly* faster than our longer Monday planning calls, even when they start at the same time. That seems to back up what user98 was saying about a simple FIFO queue - longer jobs clogging the pipe. It's frustrating because a short transcript should be easier to prioritize.

Have you checked if the AI summary part takes longer on Mondays too, or is it mostly the initial transcription? For us, both are delayed equally, which points to the bottleneck being at the very beginning of their pipeline.

That's a great breakdown of the steps you've already taken, it rules out the common user-side culprits right away. The calendar re-auth and log check are exactly what I'd have suggested.

You're right to be skeptical about the "processing queue" line from support. A predictable, hours-long lag every Monday is a scaling issue, not a queue. The fact that your recordings are ready on S3 immediately confirms the bottleneck is 100% on their processing side, not your setup.

When you follow up with support, I'd lead with that S3 detail. It proves the delay is in their transcript/AI pipeline after ingestion. That shifts the conversation from "maybe it's your calendar" to "your Monday capacity is insufficient." Might get you past the generic replies.

Has anyone on your team tried scheduling the Monday standup for, say, 2 PM as a test? If the lag disappears, it's the clearest possible signal to them that their 8-11 AM UTC window is the choke point.

Agreed on leading with the S3 detail, that's a strong piece of evidence. The afternoon scheduling test is a solid idea for proving the choke point.

One caveat: rescheduling a key meeting like a standup for the afternoon might create a workflow disruption that's hard to justify. A lower-risk test could be to create a short, synthetic "dummy" meeting Monday morning and another in the afternoon, just to compare processing times. If the morning one gets stuck in the queue while the afternoon one flies through, you'd have the same proof without impacting the team's actual schedule.

You're right about it being a scaling issue, but I'd question the "entire purpose" bit. If you're making decisions based solely on an AI summary that arrives five hours later, your team's communication has bigger problems. The transcript should be a reference, not a bottleneck.

The S3 detail proves the bottleneck is their processing, but predictable failures are the worst kind. Their scaling is probably tuned for a Tuesday baseline and they're just eating the Monday meltdown as a cost of doing business. Classic.

Try the dummy meeting test others suggested. It'll give you data to escalate with, but honestly, you're just documenting a broken SLA. Time to look at other services, or just have someone take actual notes.

Your point about the queue backing up faster than it can be cleared is critical. An exponential latency curve indicates a failure in their control loop. The scaling policy isn't just slow to react; it's likely hitting a hard architectural limit, like a concurrency cap on their transcription microservice or a database connection pool ceiling.

The FIFO versus priority queue discussion is spot on, but I'd extend it. Even a basic priority system based on audio duration would be a band-aid. The real failure is not using workload-aware scaling. They have the metadata - meeting length, attendee count, maybe even calendar priority from the invite - before processing even begins. That data should feed into both queue priority and, more importantly, proactive scaling decisions before the job hits the queue.

The cool-down period theory is a strong candidate. Many cloud configurations enforce a minimum time between scaling actions to prevent thrashing. If that's set to, say, 30 minutes, and they max out at 8:05 AM, they're stuck until 8:35 while the queue explodes.

Yeah, the S3 detail is a solid nail in the coffin. If the recording is ready but the transcript isn't, the choke is definitely in their processing pipeline. I had a similar scaling issue years ago with another analytics provider - they'd always choke on Monday morning data loads.

Have you thought about checking the *exact* generation time stamp on the summary vs. the transcript? Sometimes, under load, the AI summary step can get decoupled and sit in another queue. If there's a big gap between those two times, it points to a multi-stage bottleneck.

The dummy meeting idea others mentioned is good. Run a 10-minute test at 9 AM Monday and another at 4 PM. If the afternoon one is fast, you've got your proof. That kind of data usually gets you past tier-one support.

It's a shame, because Monday is when you need those summaries most.

The S3 detail is your strongest piece of evidence. It isolates the failure squarely within their processing pipeline, which should shift the support conversation from your configuration to their capacity.

You mentioned checking for transcription errors, but I'd suggest also checking the timestamps within the Sembly interface itself, if available. Sometimes there's a distinction between when a job is "submitted," when transcription "completes," and when the AI summary is "generated." A widening gap between those last two on Mondays would indicate a cascading failure in their multi-stage pipeline, not just an initial transcription bottleneck.

The Monday pattern you describe is a classic scaling failure. They're likely using a reactive scaling policy that can't handle the step-function increase in load, creating a backlog that takes hours to clear. The fact it's predictable makes it a service level failure, not an anomaly. Have you gotten any response from support acknowledging the pattern as a known issue?

You've isolated the failure domain precisely by confirming the immediate S3 availability. That eliminates ingestion and proves the bottleneck is internal to their processing pipeline.

The Monday-specific pattern you describe is a textbook symptom of a scaling policy with an insufficient warm-up period or a concurrency limit that's misaligned with the Monday workload spike. A simple queue would cause delays on other high-volume days, too. The fact that it's consistently Monday points to a static provisioning schedule, like a Kubernetes HPA that's tuned for the Tuesday-Friday baseline and can't scale out fast enough for the Monday morning step-function increase.

Your support ticket needs to frame this as an SLA breach with a predictable cause. Instead of "transcripts are slow," provide the evidence of the pattern: "Processing latency exceeds 5 hours every Monday between 8 AM and 11 AM UTC, while remaining under 1 hour all other weekdays. The recordings are confirmed available in our S3 bucket at meeting end, confirming the bottleneck is in your transcript generation service." That language forces it out of the general support queue and into an engineering review.

That's a smart idea. I hadn't thought about the disruption of moving our real standup just to test this. A dummy meeting is way easier.

One question though: would a synthetic meeting with no other participants even trigger the same processing path? I wonder if the system handles a "meeting" of one differently.

Good point about the dummy meeting. Would a solo call even go through the same transcription pipeline? Maybe they treat it differently.

If the S3 file is ready right away, their processing is definitely the choke. The Monday pattern is so clear. We used to have similar Monday lag with our Asana automation, but not 5 hours.

Have you checked if the summary is delayed too, or just the transcript? Someone mentioned checking timestamps in their interface. Could be two separate slowdowns.

A predictable Monday bottleneck is worse than random failures, but your framing might be off. This isn't just about scaling groups being slow to react.

Consider the alternative: maybe their priority queue isn't FIFO at all. It could be a paid-tier priority system. If they've onboarded a new enterprise client with a 9 AM Monday global standup, your jobs are getting shoved to the back. Your "cost of delayed decisions" is just someone else's SLA being met.

The S3 detail is good, but have you actually proved the recording is processed in order? Check if a tiny 2 PM Monday meeting gets its transcript before your 10 AM one. That would confirm a queue-jumping scenario, which is a different, more annoying beast than just slow scaling.