Logs Explorer / Studio Logs page auto-runs a query on load before filters are set, inflating Log Query usage

[ahpiau18]

Problem

When opening the Logs page in Studio (/project/_/logs/explorer or any individual log category page), a query is automatically executed immediately on page load using default settings (e.g. "Last 60 minutes", no filters, sometimes multiple log sources selected). This happens before the user has any chance to narrow the time range or apply filters.

Since Log Query usage is billed/metered by data scanned, this means every single visit to the Logs page — even one that's about to be immediately refined — incurs an unnecessary full/broad scan first.

Impact

For projects that rely on manually checking logs during high-traffic events (e.g. a promotion launch), repeatedly opening the Logs page to check on things can generate a surprisingly large amount of Log Query usage, even when each individual check is brief and the user's intent was to look at a narrow window. In our case, this pattern alone was enough to push Log Query usage from an expected ~1-5 GB/day into the hundreds of GB/day range, without any scripts or automation involved — just a person opening the page repeatedly during a stressful launch period.

This creates a confusing gap between "how much I think I looked at" and "how much was actually scanned," and makes the query allowance feel punishing for exactly the kind of manual, ad-hoc debugging it's meant to support.

Suggested solutions (any of the below would help)

Don't auto-run a query on page load. Show the filter UI first (time range, sources, level, etc.) with a "Run query" button, similar to how the SQL-based Logs Explorer already requires an explicit Run action.
Alternatively, default to a much smaller time range on load (e.g. last 5 minutes) rather than 60 minutes, so the "default" cost is minimal.
Surface the estimated/actual GB scanned for each query directly in the UI (a small "scanned X MB" indicator next to the results), so users get immediate feedback and can course-correct before repeating the same expensive query.
Debounce/coalesce rapid successive filter changes into a single query instead of firing a new query on every keystroke/toggle.

Additional context

We only discovered this was happening after digging into our organization's usage page and seeing Log Query usage in the hundreds of GB range despite Log Ingest being under 1 GB — there was no obvious way to correlate "manually checking the dashboard during launch week" with that scale of usage until we reasoned through it manually. A clearer feedback loop in the UI itself would have prevented this.