🚨 Logstash Error Guide: 'Failed parsing date from field' — Fix the date Filter Pattern

Overview

The Logstash date filter parses a timestamp string out of a field and sets it as the event’s @timestamp. When the value in that field does not match any of the patterns you gave it, the filter cannot convert it — so it logs a warning, leaves @timestamp at the current ingest time, and adds a _dateparsefailure tag. The warning in /var/log/logstash/logstash-plain.log looks like this:

[WARN ][logstash.filters.date][main][7c2e...] Failed parsing date from field {:field=>"log_timestamp", :value=>"10/Jul/2026:10:00:01 +0000", :exception=>"Invalid format: \"10/Jul/2026:10:00:01 +0000\"", :config_parsers=>"ISO8601", :config_locale=>"default=en_US"}

The details after :exception are the useful part: it tells you the exact :value it received and the :config_parsers it tried. Here the field held an Apache-style timestamp, but the filter was only configured with ISO8601, so no parser matched. The result is a _dateparsefailure tag and an @timestamp that reflects when Logstash processed the line, not when the event actually happened — which quietly corrupts every time-based query and dashboard downstream.

Symptoms

• Events carry _dateparsefailure in their tags field, and @timestamp equals the ingest time rather than the event time.
• Kibana time-series and histograms bunch every event around “now” instead of spreading across the real event times; back-filled logs all land in the current minute.
• logstash-plain.log shows repeated Failed parsing date from field WARN lines naming the same :field and :value.
• The failure rate correlates with one source or one format — often a source that emits month names, 12-hour clocks, or a non-US locale.
• Some events parse fine and others fail, because the field mixes two formats (for example ISO8601 from one service and epoch millis from another).

Common Root Causes

• Pattern does not match the value — the single most common cause. The match format string does not describe the actual timestamp (e.g. matching ISO8601 against dd/MMM/yyyy:HH:mm:ss Z).
• Wrong token casing — Joda/Java date tokens are case-sensitive: MM is month, mm is minute; HH is 24-hour, hh is 12-hour; DD is day-of-year, dd is day-of-month. A single wrong case fails every line.
• Locale mismatch on month/day names — parsing Jul/Tue requires locale => "en"; on a host with a non-English default locale the month name will not resolve.
• Timezone ambiguity — the timestamp has no offset and you did not set timezone, so parsing is inconsistent or shifts the value.
• Epoch confusion — using UNIX for millisecond epochs (needs UNIX_MS) or vice-versa, producing wildly wrong or unparseable times.
• Wrong source field — match => [ "timestamp", ... ] when the value actually lives in log_timestamp or a nested field, so the filter reads an empty/absent field.
• Fractional seconds or extra precision — the value has .SSSSSS microseconds or a Z literal your pattern does not account for.

Diagnostic Workflow

Confirm the config parses before you debug the data, so you are not chasing a syntax error:

sudo -u logstash /usr/share/logstash/bin/logstash \
  -f /etc/logstash/conf.d/app-date.conf \
  --config.test_and_exit --path.settings /etc/logstash

The fastest way to test a date pattern is a tiny stdin/stdout pipeline you run in the foreground and feed one representative line. Logstash .conf uses a Ruby-like DSL, so this is shown as ruby:

input { stdin { } }

filter {
  # Suppose the raw line already put the timestamp into [log_timestamp]
  grok {
    match => { "message" => "%{HTTPDATE:log_timestamp} %{GREEDYDATA:rest}" }
  }

  date {
    match => [ "log_timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
    target => "@timestamp"          # default, shown for clarity
    timezone => "UTC"               # only needed when the value has no offset
    locale => "en"                  # required to parse English month names like "Jul"
    tag_on_failure => ["_dateparsefailure"]
  }
}

output { stdout { codec => rubydebug } }

Run it and paste a real line; rubydebug prints the resulting @timestamp and any tags, so you can see instantly whether the pattern matched:

echo '10/Jul/2026:10:00:01 +0000 GET /health' | \
  sudo -u logstash /usr/share/logstash/bin/logstash \
    -f /etc/logstash/conf.d/date-test.conf --path.settings /etc/logstash

If it still fails, inspect the exact bytes of the field — a stray trailing character or non-breaking space defeats an otherwise-correct pattern — and grep the log for the reported value:

grep 'Failed parsing date' /var/log/logstash/logstash-plain.log | tail -n 5

Example Root Cause Analysis

A team shipped an Apache access-log pipeline. grok correctly extracted the timestamp into log_timestamp, but every event ended up tagged _dateparsefailure, and Kibana showed all traffic collapsed into the current minute. The log named the value clearly:

Failed parsing date from field {:field=>"log_timestamp", :value=>"10/Jul/2026:10:00:01 +0000", :config_parsers=>"dd/MMM/yyyy:hh:mm:ss Z"}

The value was a standard Apache timestamp. The pattern was almost right — but it used hh (12-hour clock) where the log emits a 24-hour hour, and it omitted locale, so on this non-US host the month token MMM could not resolve Jul. Two subtle mismatches, both invisible until you compare the token string to the actual value character by character:

# before — 12-hour token, no locale
date { match => [ "log_timestamp", "dd/MMM/yyyy:hh:mm:ss Z" ] }

# after — 24-hour token, explicit English locale
date {
  match  => [ "log_timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  locale => "en"
}

The offset +0000 in the value meant timezone was unnecessary — Z in the pattern consumed it. After the change, the stdin test printed a correct @timestamp of 2026-07-10T10:00:01.000Z with no failure tag, and the deployed pipeline spread events across their true event times. The takeaway: read the :value in the warning, then map it token by token — HH vs hh and a missing locale are the two mistakes that cause the overwhelming majority of _dateparsefailure cases.

Prevention Best Practices

• Copy the failing :value straight from logstash-plain.log and build the pattern token-by-token against it; never reuse a pattern from another source without checking.
• Memorize the case-sensitive tokens that bite most often: MM month vs mm minute, HH 24-hour vs hh 12-hour, dd day-of-month vs DD day-of-year, yyyy vs YYYY (week-year).
• Always set locale => "en" when the timestamp contains English month or day names, regardless of the host’s system locale.
• Set timezone explicitly whenever the value has no offset, so ingest-host timezone changes can never shift @timestamp.
• Provide multiple patterns in one match array ([ "ts", "ISO8601", "UNIX_MS", "dd/MMM/yyyy:HH:mm:ss Z" ]) when a field legitimately carries more than one format.
• Alert on the _dateparsefailure tag in your pipeline so a producer format change surfaces immediately instead of silently mis-timestamping data.

Quick Command Reference

# Validate the pipeline syntax
sudo -u logstash /usr/share/logstash/bin/logstash \
  -f /etc/logstash/conf.d/app-date.conf \
  --config.test_and_exit --path.settings /etc/logstash

# Test a date pattern against one line with rubydebug output
echo '10/Jul/2026:10:00:01 +0000 GET /health' | \
  sudo -u logstash /usr/share/logstash/bin/logstash \
    -f /etc/logstash/conf.d/date-test.conf --path.settings /etc/logstash

# See the exact value and parsers Logstash tried
grep 'Failed parsing date' /var/log/logstash/logstash-plain.log | tail -n 10

# Count date-parse failures
grep -c '_dateparsefailure\|Failed parsing date' /var/log/logstash/logstash-plain.log

# Restart and follow the log
sudo systemctl restart logstash && \
  sudo tail -f /var/log/logstash/logstash-plain.log | grep -i date

Conclusion

Failed parsing date from field and the _dateparsefailure tag mean the date filter received a timestamp string that none of its patterns could match, so it left @timestamp at ingest time — silently corrupting every time-based view built on that data. The warning hands you everything you need: the :field, the exact :value, and the :config_parsers it tried. Map the value to the pattern token by token, watching for HH vs hh and MM vs mm, add locale => "en" for month names, and set timezone when there is no offset. Test with a one-line stdin pipeline and rubydebug before deploying, and alert on _dateparsefailure so the next upstream format change is caught the moment it happens.