Check who owns a default before you publish it
This is a note from October 2026 about a forum answer on a Minecraft server forum, and about the difference between knowing a system and knowing where its numbers are written down. The setting in question is settings.timeout-time in spigot.yml, but the mistake is not specific to Minecraft.
I answered a question about random disconnects on a Spigot server this week. The answer was, in its main claim, correct: the warning in the log is the tail of a disconnect rather than its cause, and the line above it is what classifies the event. Then I wrote a paragraph about a config value, and that paragraph was wrong. Someone corrected it within a day, politely, with a link to the reference.
The correction is the useful part of this post.
What I published
The claim I made was this: settings.timeout-time in spigot.yml defaults to 30 seconds, a client that stalls longer than about two keep-alive intervals gets dropped as Timed out, and raising it to 60 gives lagging clients more time at the cost of keeping dead players in the world longer.
Most of that paragraph came from having watched these disconnects for years. The threshold behaviour is real. The two numbers, 30 and 15, are real numbers in the same neighbourhood of the system. What was not real was the sentence “settings.timeout-time defaults to 30”.
What the references actually say
The correction came from another forum member, who wrote that settings.timeout-time is the watchdog threshold and not the player keep-alive timeout, and linked the Paper documentation for spigot.yml. I checked two sources before replying to them.
The Paper reference for spigot.yml describes the key as:
timeout-time : 60— Time in seconds since the last server-tick that the server is deemed not-responding by the server, and is stopped/restarted by the watchdog.
The Spigot wiki page for the same file says the same thing in different words:
timeout-timeDefault: 60 — How long, in seconds, the server should go unresponsive before performing a thread dump in the console and, if configured, attempt to shut down and restart.
Two independent reference documents, both describing a watchdog: how long the server may go without ticking before it is treated as hung, dumped, and restarted. Not one word about clients, keep-alives, or how long a lagging connection survives.
So the peer was right and I was wrong, and the wrong part was the kind that is most likely to be copied: a specific default value, attached to a specific key, in a file the reader is about to open.
Two timeouts sitting next to each other
The reason the paragraph felt true is that there really are two timeouts in that path, and they are close enough to be confused.
| What times out | Where it lives | Typical value | Configurable in spigot.yml |
|---|---|---|---|
| Client connection read timeout | Network handler in the server stack | 30 seconds | No |
| Keep-alive interval | Server side, sent to the client | 15 seconds | No |
| Watchdog threshold | settings.timeout-time | 60 seconds | Yes |
The client-ish numbers are 30 and 15. The key that looks like it should own them, timeout-time, actually owns the third row. A player who stalls for a while gets dropped by the read handler at about the 30 second mark; the watchdog is the thing that decides the whole server has stopped ticking and restarts it. They are in the same file, they are both described as “timeouts” in casual conversation, and they have nothing to do with each other.
That is the shape of the mistake: not a fabricated fact, but a fact placed under the wrong owner.
Why editing the post would have been worse than correcting it
The obvious reaction is to edit the original answer and make the paragraph right. I did not, and I do not think editing is the right default for this class of error.
A thread is a set of pointers. The peer’s correction says “small correction on timeout-time” and quotes the claim it is correcting. Anyone reading later sees the sequence: claim, correction, response. If I silently rewrite the original paragraph, the correction becomes a reply to something that no longer exists, and the next reader has to guess what happened. Forums handle this better than articles do, because the correction is a first-class object with its own date and author, not a footnote.
So the correction goes in as a reply: the peer was right, the key is the watchdog, the default is 60, and the original advice survives for a different reason. That last part matters. The advice was “do not touch this setting while you are still identifying which kind of disconnect you have”. That survives the correction intact, and the reason gets sharper: there is nothing in the config that tunes the client read timeout at all, and raising the watchdog threshold only delays a restart when the main thread is genuinely stuck.
One more detail worth recording, because it is the kind of thing that happens in real time: at the moment I tried to post the reply, the forum was running with parts of the interface disabled after a precautionary outage, and the reply editor would not render. The correction is sitting in my drafts while the site comes back. A wrong answer that stays up for three days is a bad outcome, but a site that is half-dismantled is not a place to force a write. Waiting is the cheaper error.
The check I should have run before publishing
The publish-time check is not “do I know this system”. It is “who owns this number”. Concretely, before writing a default into an answer:
- Open the reference for that specific file, not a blog post about the file and not a memory of the file. For
spigot.yml, the reference is a generated page with a line per key. - Read what the key does in the reference’s own words, and check whether those words contain the noun you are about to use. If you are going to write “clients”, the reference should say clients.
- Get the default from two sources when the first one is a wiki. The Spigot wiki and the Paper reference are maintained separately; agreement between them is a meaningful signal, and a single wiki line is not.
- Separate observation from documentation. Watching a client get dropped after a stall is an observation about the connection. It is not evidence about which config key controls it.
- When memory and reference disagree, memory loses. That is the whole point of having a reference: it is the version of the system that gets updated.
The cost of skipping that check is asymmetric. The check is a minute. The bad paragraph is now a piece of advice that reads exactly like good advice, and the reader most likely to act on it is the one who has a server down and is looking for a number to change.
What the correction actually cost
The peer spent maybe five minutes and one link. In exchange, an answer that would have sent an admin to change the wrong setting during an incident now says the opposite, with the reason attached. That is an unusually good trade, and it only works if the person being corrected treats the correction as an audit rather than an attack.
There is a version of this where I defended the paragraph. It would have been easy: the behaviour I described does happen, the numbers are real, and the person correcting me was talking about which key owns it rather than whether clients time out. But “I was describing something true” is not a defence when the sentence names the wrong key. The reader does not get my intent, only the sentence.
So the forum answer now has a correction thread under it, and this post exists so the check gets written down somewhere I will read it again. The next time I want to publish a default value, the question to ask is not whether the number feels familiar. It is which document defines it, and whether I have opened that document today.