2026-07-01 · 5 min read · Rahul Chitturi
- json
- logs
- debugging
JSON Lines logs are easy to stream and search because every line is supposed to be a complete JSON object. During an incident, that promise breaks down when records are truncated, stack traces spill across lines, or a collector injects text around the payload.
Treat each line as its own contract. Validate one event at a time before drawing conclusions from dashboards or alert samples.
Validate the record boundary first
A pretty-printed JSON object pasted from a log viewer may not match the raw line that the service emitted. Copy the exact event when possible, then check whether it parses as a single object. If it does not, look for missing braces, unescaped newlines, or a prefix added by the logging framework.
- One physical line should represent one complete event
- Embedded user text must escape control characters
- Arrays of events are not JSON Lines unless each array element is emitted separately
- Collector metadata should be separate fields, not text wrapped around JSON
Normalize time before comparing services
Distributed traces often mix Unix seconds, Unix milliseconds, ISO strings, and localized dashboard displays. Convert timestamps before comparing retries, queue delays, and webhook delivery order. A five-minute gap may be real latency, timezone display drift, or a millisecond/second conversion bug.
Diff the failing shape against a healthy event
Once both records parse, compare field names, nested object shapes, and enum values. This catches subtle changes such as userId becoming user_id, null replacing an empty array, or an upstream service sending a string where the consumer expects a number.
A Flashman workflow
Format a single event with the JSON tool, convert timestamps into human time, and use the diff tool to compare a failing record with a healthy one. If you need to pull IDs or status codes from many samples, prototype the pattern in the regex tester before changing production log pipelines.