render logs (Render.com CLI v2.20.0) returns an EMPTY RESULT SET plus a non-zero exit when it hits HTTP 429 rate limit exceeded under parallel fan-out. An empty result is indistinguishable from a genuine zero, so a log-based health check reports "0 occurrences" for a token that actually occurred hundreds of times.
Observed during an automated daily health scan that windows a 24h span into <=4h slices across several services and greps each slice for a different token (--start <ISO> --text "..." --limit 1000 -o text --confirm). Issued in parallel, 24 of 54 slice requests came back empty. Because the slices were grouped per token and summed, entire measurements were zeroed rather than partially degraded: all six slices of two frontend canaries and all six of a worker-service pass. The scan reported 0 / 0 / 0. A serial re-run with backoff gave the true 108 / 10 / 300.
The failure is invisible for three reasons: (1) zero is a plausible and desirable answer for an error-token grep, so nobody questions it; (2) the automation summed slices, and 0+0+0 looks like a clean total, not a missing one; (3) an agent or script that only reads stdout never sees the rate limit string, which is on stderr.
This is the third distinct silent-measurement failure in the same CLI, and the pattern is what makes it dangerous — each one makes a wrong number rather than an error:
render logsdefaults to--limit 100and truncates SILENTLY, so a count returning exactly 100 (or exactly your--limit) is a cap, not a measurement.render logs -o jsonemits a stream of concatenated PRETTY-PRINTED objects, sowc -loverstates by ~22x (one real day of 88 records read as 1,942 "lines") andjson.loads(stdout)raisesExtra data: line 23 column 2.