Set twice
Redis silently uses the last one, so the edit above it does nothing
maxmemory 1gb appendonly yes maxmemory 2gb
Paste a redis.conf to see how Redis will actually read it. The file format has three details that a quick glance misses: values can be quoted, some directives accumulate rather than replace, and a duplicated scalar silently keeps only the last one.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Validate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Redis silently uses the last one, so the edit above it does nothing
maxmemory 1gb appendonly yes maxmemory 2gb
A value that stops the server starting, named exactly
maxmemory 1gb maxmemory-policy allkeys-mru
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Redis uses the last occurrence and ignores earlier ones silently. An edit made above another copy has no effect and looks like Redis ignored it.
Instead:Search the whole file for the directive before changing it.
Values can be quoted. `save ""` disables snapshotting entirely, and a naive split reads it as something else.
Instead:Respect the quoting, which is the same splitter Redis uses for inline commands.
Includes are processed positionally, so a file included at the top is overridden by everything below it, and one at the end overrides everything above.
Instead:Place the include according to which side you want to win, and say so in a comment.
redis.conf looks like a flat list of settings. It is close to that, and the places where it is not are where configurations quietly do something other than what they read as.
Set maxmemory twice and Redis uses the second one. It does not complain, it does not log anything, and the first line stays in the file looking authoritative. This is the usual explanation for an edit that appears to have been ignored: it was made above another copy of the same directive.
save takes one line per snapshot schedule, and client-output-buffer-limit one per client class. For these, repetition is the syntax rather than an override, so a tool that treats the file as a simple key-value map reports the wrong persistence policy. save "" on its own line disables snapshotting entirely, which only reads correctly if the quoting was understood.
Redis parses config lines with the same splitter it uses for inline commands, so double quotes allow spaces and backslash escapes, and single quotes allow spaces without escapes. An unbalanced quote is a startup failure rather than a warning, and there is no partial load: the server refuses to start at all.
An include is processed where it appears, so a file included at the END overrides everything above it, and one at the top is overridden by everything below. Most people assume the opposite. Anything in an included file is invisible to this page.
This carries a curated list of directives rather than a guessed complete one, so a directive it does not recognise is reported as unrecognised rather than as invalid. It also cannot see command line overrides, which beat the file, or anything set at runtime with CONFIG SET, which beats both until a restart.