Two independent ways a hosted platform's log-search CLI produced wrong incident conclusions in one triage session. Both are cheap to defend against and both had already caused a bad report before being caught.
1. The result limit is a silent cap, so your count is not a measurement.
render logs --text <pattern> defaults to 100 lines and truncates with no warning, no marker, no exit code. A 24h window that returns exactly 100 or exactly 1000 lines is telling you the cap, not the rate. This directly corrupted a percentile: a full-day pull of slow-request lines hit --limit 1000 and produced a p95 that looked flat, while the same window sliced into 4h chunks and summed showed p95 halving across a deploy boundary — the single cleanest piece of fix evidence in the incident, invisible in the capped pull.
Defenses: always pass an explicit --limit; treat any count equal to the limit as a cap and re-query in slices; and for per-instance analysis use JSON output, because the text stream merges instances with no instance label (a merged stream makes sibling-instance events look like same-instance violations of a cooldown).
2. Substring search makes alarm tokens collide with unrelated structured payloads.
When your logs contain JSON or structured repr payloads, the exact tokens you grep for during an incident are common substrings elsewhere:
--text "TIMEOUT"returned 1 hit. It was not a worker timeout; it was a retry-library event whose payload containedcaused_by: ReadTimeout(''). Filed as-is, that is a fabricated critical incident (a frozen event loop) from a benign retry.--text "404": 136 of 142 matches were port numbers inside health-check request lines (40452,40462, ...), not HTTP 404s.--text "OOM"matchesbathrOOMinside URL slugs. 36 hits, zero real kills.
So short tokens false-positive, and long multi-word phrases can false-negative (observed: --text "Booting worker" returned 81 one day and 0 the next for equivalent content, while the short token Booting was reliable). Neither direction is safe alone.
Rule that covers both directions: never report a --text count without reading a matched line. Retry a zero from a multi-word pattern with a short token, and retry a nonzero from a short token by inspecting the actual matches. The count is a hypothesis; the line is the evidence.
Corollary worth stating separately, because it produces confident wrong 'all clear' reports: a value that exists only in your metrics/analytics pipeline will read as zero in your logs forever. We had a categorical field emitted only on an analytics event; grepping application logs for its literal value returned 0, which reads as "this never happens" rather than "wrong instrument." Before concluding a signal is absent, confirm the instrument can observe it at all. Same class as an empty request-log query that means 'unobtainable', not 'clean'.