A JSON log can be valid and still arrive as plain text, split into several events, show the wrong time, fail indexing, or appear incomplete. The cause is often not JSON syntax alone: each stage of the logging pipeline—event framing, parsing, timestamp mapping, indexing, and display—has to agree on what the record contains. Trace one raw event through those stages to find where it changes.
Start by tracing one raw event through the pipeline
Before changing a parser or schema, capture the exact payload the shipper receives and compare it with what the aggregator displays. Preserve the original so you can distinguish an input problem from a transformation or indexing problem.
As an Amazon Associate I earn from qualifying purchases.
- Inspect the raw input. Determine whether it is one JSON object per line, a pretty-printed object spanning multiple lines, or plain text with JSON embedded in a prefix or suffix. A line such as
INFO request: {"status":200}is not itself a valid JSON document. - Check event boundaries. Confirm whether the collector treats the payload as one event or several. A parser cannot reconstruct a record that the input stage has already split incorrectly.
- Check parsing. Verify that the parser reads the field containing the JSON, then inspect both its output and its failure behavior.
- Check timestamp mapping. Compare the parsed time value, including its format, unit, and timezone, with the timestamp the product displays.
- Check indexing and display. Look separately for rejected events, incompatible field types, truncation, and display behavior.
Processor names and limits vary by vendor and version. Use the documentation for the product and version actually deployed.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why is my JSON log showing up as plain text?
Parsing and event framing are separate operations. A JSON decoder can only parse the intended record if the collector has delivered the record as a unit and the parser is pointed at the field that contains the JSON.
#1 Best Overall
Confirm the JSON is where the parser expects it
Check the event before parsing. A field named message may contain only part of the payload, or it may contain a text prefix followed by a JSON object. Extract the JSON segment or use a format-aware parser for that input; do not assume the entire field is a JSON document.
OpenSearch Data Prepper’s parse_json processor defaults to the message field and supports configurable source and destination fields, including nested fields. It also documents skip and skip_silently error-handling modes. Choose failure handling deliberately: retaining the raw event or routing parse failures for inspection is safer during troubleshooting than silently dropping them. See the OpenSearch Data Prepper parse_json processor documentation.
Distinguish automatic parsing from an explicit processor
Datadog says it automatically parses JSON-formatted logs and supports Grok parsing for other formats. When JSON appears after raw text, its documentation describes using a JSON filter for the nested JSON segment. See Datadog’s log pipeline documentation.
Other systems may require an explicit pipeline processor or collector configuration. OpenSearch documents JSON and multiline codecs for Logstash as distinct tools: the JSON codec decodes JSON, while the multiline codec merges multiple line events into one. See OpenSearch’s Logstash plugin documentation.
Why are my JSON logs split across multiple events?
Many log shippers and collectors use line breaks to decide where an event ends. That works for one compact JSON object per line, but a pretty-printed object spans several physical lines. Without source-appropriate multiline framing, those lines can become separate events, each of which may be invalid JSON on its own.
Configure multiline framing before JSON parsing when one logical record spans multiple lines. Conversely, avoid a rule that merges adjacent records if each line already represents an independent JSON object. Logstash’s multiline codec merges multiple line events into one; whether that is appropriate depends on the actual input framing, not on the fact that the content is JSON.
Splunk’s versioned Cloud documentation also warns that line-breaking choices affect performance. Its cited documentation applies to Splunk Cloud documentation version 9.3.2408, so check the corresponding guidance for your deployment rather than treating one setting as universal: Splunk Cloud event line-breaking documentation.
Why is the timestamp wrong after parsing?
Extracting a date into a JSON field does not necessarily make that value the official event timestamp. Some products initially use ingestion time, then require a separate remapping step to use the parsed event time. Datadog explicitly says that parsing a date alone does not set the official log date; its log date remapper assigns it. See Datadog’s pipeline documentation.
Check the value, format, unit, and timezone
Inspect the parsed value rather than guessing from how it looks. Determine whether it represents seconds, milliseconds, or another unit; identify its timezone; and check whether the parser’s expected pattern matches the source. Do not multiply a value by 1,000 unless you have confirmed it is seconds and the target expects milliseconds.
Datadog’s timestamp troubleshooting guidance lists ISO8601, UNIX milliseconds, and RFC3164 formats, and cautions that nanosecond epoch values may not be recognized. Its suggested conversion and remapping steps are Datadog-specific, not a universal rule for aggregators. After applying the appropriate remapper, compare the displayed event time with the source value. See Datadog log troubleshooting.
Elastic’s ingest guide identifies inconsistent date formats, incorrect timezone settings, and incorrect timestamp patterns as common problems. It documents ISO8601, UNIX, UNIX_MS, and TAI64N options alongside Java time patterns. Use the format that matches the source field and the installed Elastic version: Elastic’s log ingestion guide.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhy can valid JSON still fail indexing?
Parsing and indexing are different checks. A processor may produce a syntactically valid object, yet the destination can reject it or handle fields unexpectedly because their types do not fit the destination’s current schema or mapping. For example, an attribute that the destination expects to be one type may arrive with a different type.
Rank #3
- Inspect the parsed event and its field types before it reaches indexing.
- Check the destination’s current schema or mapping, plus rejection details for the specific event.
- Separate parse errors from indexing errors; a successful parse does not prove the event was indexed.
- Do not blindly change a shared mapping or delete indexed data to make one event fit. Check the exact product and version’s guidance before changing a destination schema.
Processor documentation for OpenSearch Data Prepper and Elastic ingest pipelines explains parsing and pipeline configuration, but mapping remedies depend on the product, version, and existing destination schema. See the OpenSearch processor documentation and Elastic ingest guide for their respective pipeline behavior.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Could an event-size limit make the log look malformed?
Yes. A large event may be truncated even when its original JSON was valid. Datadog’s current troubleshooting documentation, accessed in 2026, says logs above 1 MB are truncated. For indexed logs, it states a 75 KiB message-field limit and a 25 KiB limit for non-message fields. Datadog also says full text remains visible in regular Log Explorer list queries. These are Datadog product limits, not general limits for log aggregators; check the current product documentation for the limits that apply to your account and workflow: Datadog log troubleshooting.
How do you test a fix without hiding another failure?
Test a representative event through the complete pipeline, not just the JSON decoder. Keep the raw input available so the output can be compared with its source. Where the platform supports simulation, use it before rolling out a pipeline change; Elastic’s ingest guide specifically describes testing with its simulate API.
- Save a representative raw event, including any prefixes, line breaks, and timestamp value.
- Validate that the intended JSON segment is syntactically valid.
- Confirm the framing rule produces exactly one event per logical record.
- Parse the field that actually contains the JSON and inspect the resulting fields and types.
- Trigger or inspect parse-failure handling to ensure a bad event is retained, routed, or reported as intended.
- Compare output fields with the destination schema and inspect any indexing rejection details.
- Verify that the displayed timestamp matches the source event after the intended remapping.
- Check the final event for truncation or field-size effects.
Elastic’s workflow and simulate API are documented at Elastic’s log ingestion guide. A successful simulation or parse test still does not replace checking the deployed destination schema, timestamp configuration, and size behavior.
Which part of the pipeline should you change?
Make the correction at the stage where the observed output first diverges from the raw event. The distinction matters: a parser cannot fix a record split before it reaches parsing, and a timestamp parser cannot remap the official event time unless the product’s timestamp mechanism is configured to use that field.
- Wrong number of events: correct the source-appropriate framing or line-breaking rule.
- One event, JSON still embedded in text: point the parser at the actual JSON field or extract the JSON segment.
- Fields parse but time is wrong: correct the timestamp pattern, unit, timezone, or explicit event-date mapping.
- Parsed event rejected: inspect destination field types and rejection details before changing mappings.
- Fields or text are incomplete: check the product’s event and field-size limits and its display behavior.
These controls are not identical across OpenSearch, Logstash, Data Prepper, Datadog, Elastic, and Splunk. Processor behavior, timestamp support, limits, and line-breaking settings are version- and product-specific; consult the documentation for the platform and version in use.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
