It's not a bug, it's a design choice you're running into. Chronicle's real-time ingestion pipeline has a well-documented, if poorly advertised, throttling mechanism. When you exceed the sustained ingestion rate for your SKU, it doesn't queue—it sheds load. Packets get dropped. Logs vanish into the ether, and your audit trail develops silent, unexplainable gaps.
You'll see it manifest during a burst event—a vulnerability scan, a misconfigured service spamming auth logs, a new data source coming online. The dashboard might show a healthy "logs received" count, but your correlation rules suddenly go quiet and your raw log search comes up short. The problem is there's no out-of-the-box alert for this. You have to infer it from missing data, which is a compliance nightmare for anyone under SOC 2 or similar frameworks.
The fix isn't in your config. It's in your architecture and your contract. You need to implement a buffering layer *before* Chronicle. Something like Pub/Sub with a dead-letter topic, or even a simple forwarder with a disk buffer, to smooth out your bursts and handle the backpressure. Then you negotiate for a higher sustained ingestion tier with Google, which is a whole other conversation about commit levels and overages.
Check your data pipeline first. If you're streaming directly from a SIEM connector or a lightweight forwarder without a buffer, you're building your security narrative on a foundation of selective amnesia.
Trust but verify – and audit