Missing Field Detector

Structured logs are only as useful as their fields. When an exporter forgets a field — no user, no status, no resource — every downstream dashboard, alert, and audit that depends on that field silently goes dark, with no error and no obvious symptom until someone asks a question the data can no longer answer. Missing Field Detector declares the fields a healthy record must contain and sweeps the log for every record that is missing any of them.

It reads records in either of two shapes. In key=value mode, each line is split into whitespace-, comma-, and semicolon-separated tokens, and a declared field is considered present if some token begins with fieldname= — so user=alice satisfies a required user field, while a token like username=alice does not, because the required key must match exactly up to the equals sign. In JSON mode, each line is parsed as a standalone JSON object and a field is present when that exact key exists on the object, regardless of its value — even an empty string or an explicit null counts as present, since the detector checks for the key’s existence, not its value.

The tool checks each declared field for presence on every line and produces two views: a per-field breakdown showing how many records are missing that field and which line numbers they are on, and a per-line list of the worst offenders — records missing the most fields at once. A completeness summary tallies how many records had every required field versus how many were missing at least one.

• Declared field list — a simple comma-separated list of required keys, trimmed and validated before the scan runs.
• key=value mode — token-level presence checks against fieldname= prefixes, tolerant of whitespace, comma, or semicolon-separated records.
• JSON mode — object-key presence checks using each line as an independent JSON record.
• Per-field missing counts and line numbers — see exactly which field is breaking and where, not just an aggregate count.
• Worst-records report — records sorted by how many required fields they are missing, so the most broken lines surface first.
• Completeness summary — a clear count of fully-formed versus incomplete records across the whole file.
• Invalid-JSON reporting — in JSON mode, unparseable lines and non-object JSON values are called out by name rather than silently skipped or miscounted.
• 100% local — nothing leaves the browser, no upload, no server round trip.

1. Paste your log into the text box — one record per line, in either key=value or JSON form.
2. List the required fields as a comma-separated list of exact key names, for example user,action,resource,status.
3. Pick the record mode — key=value tokens for classic structured logs, or JSON objects for logs emitted as JSON lines.
4. Click Detect missing fields. Every non-blank line is checked against every declared field.
5. Read the summary cards — records checked, how many were complete, how many were incomplete, and how many fields you declared.
6. Scan the per-field cards to see at a glance which required field is breaking most often, then check the worst-records list for the specific lines that need the most correction.
7. Copy the report and hand it to whoever owns the exporter or the pipeline stage that is dropping the field.

Example 1 — Audit completeness. An audit contract requires user, action, resource, and outcome on every record. Run the detector over a month of records in key=value mode and every record missing an outcome is listed by line number, ready for the compliance review to demand a fix from the logging team.

Example 2 — Exporter regression. A version bump in a service silently drops the status field from some lines while leaving the rest of the format unchanged. The detector finds exactly which lines lost the field and how many, turning a vague “some dashboards look wrong” complaint into a precise bug report with line numbers attached.

Example 3 — JSON ingest QA. Before loading a batch of JSON-lines records into a data warehouse, switch to JSON mode and verify every required key exists on every line. Lines that are not valid JSON at all, or that parse to something other than a plain object, are reported separately as invalid rather than silently counted as complete or incomplete.

Example 4 — Partial rollout. During a gradual field rollout, only some services have started emitting a new trace_id field. Declaring it as required immediately shows the completeness split between services that have adopted the change and those that have not.

• Field-contract enforcement — nothing important silently missing from records your pipeline depends on.
• Two record formats — key=value and JSON, covering most structured log shapes without conversion.
• Precise locations — per-field line numbers mean no manual searching through a large file.
• Instant completeness view — spot the size of the problem before reading a single flagged line.
• Honest about invalid data — unparseable JSON is reported as invalid, not silently treated as complete or incomplete.
• Private — all processing stays local, in your browser.