investigating-logs

Pin down the change time and affected service, then run a pattern diff comparing the window after the change against a comparable baseline before it. New error templates, large rate-ratio shifts, or volume discontinuities indicate a regression.

Localize the spike with bucketed count queries, recursing into the densest time buckets. Then run a single pattern diff of the spike window against the window just before it; the top new and rate-shifted templates are the explanation.

No. Hand-written HogQL over the logs table routinely hits read-byte caps and re-derives what the dedicated log tools do in one cheap call. Reserve SQL for rare cases of joining log-derived facts with non-log data.

The severityLevels filter matches six canonical lowercase buckets against severity_text exactly. If you get zero rows, inspect the stored values with the attribute-values tool for the severity_text key to see what your services actually emit.

Pattern counts are sampled estimates, so templates rarer than roughly 1 in 10,000 rows can be invisible. Also, a tiny or empty baseline window makes everything look new in a diff, so check the baseline total count before trusting results.

Use a different approach for creating or tuning log alerts, and for analytics over product events, persons, or insights. Log investigation is for verifying health, explaining spikes, and triaging incidents in log streams.