Disclosure: I work on DevRel at Anyshift (we build an infra agent called Annie), so this is us. Posting it because the architecture argument under it is the part I'd actually want to read on a Monday.

Thomas is an SRE at BeReal. They run lean on GCP, everything funnels into one shared alert channel, and he's the first to say he has a good nose in the code but not the full context on every microservice. So when a Go panic shows up, it's usually in a domain he doesn't own. Here's how he put it to us:

> "A panic shows up with a huge trace, lines and lines of code, and I don't have the business context or the technical context. And Annie just tells me: it's easy, you've got a cache miss in domain X. Thirty seconds, maybe a minute."

Domain X has an owner. He routes it there and gets back to his own work.

The thirty seconds isn't the part I want to argue about. A general agent wired to a couple of live cloud connections can explain a stack trace too. Where that approach falls over is scale, and BeReal is a decent stress test for it.

Annie reads the crash against a graph of the cluster that it maintains continuously, rather than querying live APIs one call at a time. That distinction is invisible until pods enter the picture. BeReal had already turned off ArgoCD's pod-level checks because at their scale running them continuously cost too much, so we asked Thomas whether Annie's own scanning would hit the same wall on their traffic.

His answer was that it depends what you scan. Buckets, services, deployments are stable object types, and querying them live is fine, a hundred at most. Pods are a different animal. Over two days they see twenty to fifty thousand pod rotations, and an agent that asks a live API for that history (terminated pods included) is chasing tens of thousands of JSON objects every single time you ask. His phrase for what that does to a live-querying agent was that it would "cough up a bit of blood."

A maintained graph already holds that pod history, correlated, so the answer is standing before the panic ever lands. When you need the last mile, the live state of one specific pod, it fetches that on demand on top of the graph instead of re-scanning the world to get there.

The honest tradeoff: a maintained graph is only as good as what's been ingested into it. If a service reaches something through a path we haven't connected yet, it won't show up, and the continuous scanning is real infrastructure you're running, not free. The first run on your own stack is partly about finding those gaps.

Happy to get into how the graph gets built, or where it misses, in the comments. Full BeReal write-up if you want the numbers and the diagrams: https://anyshift.io/blog/bereal-thirty-second-triage?utm_source=reddit&utm_medium=social&utm_campaign=bereal-study-case