Skip to content
Notifications
Clear all

Has anyone benchmarked the latency between meeting end and summary delivery?

1 Posts
1 Users
0 Reactions
3 Views
(@devops_grandad)
Estimable Member
Joined: 2 months ago
Posts: 100
Topic starter   [#11338]

Alright, let's cut to the chase. I've been trialing this new wave of "AI meeting assistants" for my team's daily standups and client syncs. We've settled on Read AI for now, mostly because the transcription accuracy is decent and it hooks into Google Meet without too much fuss.

But here's my production-grade concern: the time from "meeting ends" to "summary in my inbox" feels... variable. And in my world, variable latency is just another word for "unreliable." If I'm jumping from a client call into a planning session, I need those action items *now*, not whenever their pipeline feels like it.

So I'm asking the community: has anyone done any proper, systematic benchmarking on Read's summary delivery latency? I'm not talking about gut feelings. I'm talking about the kind of data an SRE would log.

I want to know:
* **The raw metrics:** What's the average, median, and p95 latency from the meeting's recorded end time to the "summary ready" notification?
* **Variables:** Does this change meaningfully with:
* Meeting duration (15 min vs. 60 min)?
* Number of participants?
* Video on/off?
* Time of day (are their queues backed up during US business hours)?
* **Failure modes:** How often does it just... not deliver? Do you get a failed notification, or does it silently vanish into the ether?

I've started poking at this myself with a crude script that logs the end time and polls my inbox via the Gmail API, but my sample size is tiny. If anyone else has been down this rabbit hole, I'd appreciate seeing your methodology or data.

```bash
#!/bin/bash
# This is the kind of ugly, practical logging I'm starting with.
MEETING_END_TIME=$(date -Is)
# ... meeting happens ...
# Trigger some check when the email arrives
while true; do
if grep -q "Your Read AI Summary" /path/to/mail-log; then
SUMMARY_TIME=$(date -Is)
echo "$MEETING_END_TIME,$SUMMARY_TIME" >> latency.log
break
fi
sleep 60
done
```

This isn't about shaving seconds. It's about understanding the operational characteristics of a tool we're baking into our workflow. If the p99 latency is 30 minutes, I'll treat it as an async digest tool. If it's consistently under 2 minutes, I can actually rely on it between back-to-back meetings. That decision changes processes.

What have you all seen?



   
Quote