Two limits that behave nothing alike, and the interface must not pretend otherwise. Only one of them can actually switch your dashboard off.
Figure 1 — why the two are presented differently. Averaging a blocked index with an idle one would tell an operator they are fine when they are not, so the worst of the two indexes drives the strip.
The platform answers every request against that index with a refusal — reads included, not just writes — until usage returns under the limit or the plan is upgraded. It clears by itself roughly seventeen minutes after usage is back under. That is why the bandwidth warning has to arrive early: after the limit, the panel that would have shown it is dark.
Because the rolling trim runs before a write, the index never reaches its disk quota and the blackout never triggers on disk. So disk is reported as a fact about how far back the data goes — “roughly eleven days of traffic retained, limited by your plan” — rather than as a risk.
The single exception is a trim that failed while the index is genuinely near the limit. Then the blackout really is coming, and that is loud.
One call to the Opensolr control plane per refresh, which reports the index size and bandwidth against their allowances. That call is expensive — the platform derives the index size from a live status request — and Loghound writes batches every couple of seconds, so calling it per batch would cost far more than the ingestion it is protecting.
So the answer is cached with both a time and a document threshold, and between refreshes the size is projected locally from the bytes of log actually read, using an expansion factor learned from the platform’s own reported growth. Every projected figure is flagged as estimated and says so on screen.
It feeds the always-visible bandwidth strip, and it answers from the cache on all but one call in every refresh window — which matters, because the panel’s own queries consume the bandwidth this meter reports. The two indexes have independent quotas and are reported separately.
- Look at what is reading it. The panel is a consumer of this bandwidth; so is anything else you have pointed at those indexes.
- Turn off the full-text catchall if you do not use the free-text search in the session explorer. It is the biggest single component of the hits index — see the schema page for the order to turn things off in.
- Turn off the raw line copy if you will not need to re-score history under a future ruleset.
- Shorten the retention window. It is the only lever that bounds growth rather than reducing a constant.
- Or move to a plan with more. What the plans hold; the meter links there too.