Check Paper world autosave intervals without disabling saves

Paper periodically saves world changes during play. Those writes help preserve progress, but they do not replace a recoverable backup. A backup protects an earlier state from mistakes and corruption; autosave writes the current state, including changes you may later want to undo. Keep both responsibilities separate when investigating save-related pauses.

Inspect the current save path

Record the Paper build, affected world and time of any hitch. Download the relevant configuration before editing it. Check ticks-per.autosave in bukkit.yml and the world's Paper chunks.auto-save-interval setting. The latter can inherit the Bukkit interval through the value default. Read the effective configuration, including world-specific overrides, rather than changing only the first matching file.

Use the layout documented for your release. Current 26.x references describe dimension configuration paths that differ from earlier Paper layouts. A 1.21.11 server may organise world folders differently. Locate existing generated files and confirm which world they belong to; do not create a guessed directory tree copied from another version.

Choose a bounded adjustment

If a profiler or timing evidence points to save work, first check available disk space, backup schedules and simultaneous archive operations. A slow storage path cannot be repaired simply by saving less frequently. Keep a note of the original interval and change only one setting at a time.

Paper's interval is expressed in game ticks, not milliseconds. At the normal twenty ticks per second, 6000 ticks represents about five minutes, but lag changes elapsed wall time. Treat that as an explanation of units, not a universal recommended interval. Longer gaps can increase the amount of recent progress exposed to an abrupt crash.

Stop the server cleanly before editing. Adjust the existing chunks.auto-save-interval entry only if the installed release supports it. Keep saving enabled. Do not use save-off as a permanent performance fix, and do not set undocumented zero or negative values based on a forum suggestion. Leave chunk save limits and filesystem flush options unchanged in this first test.

Verify persistence and behaviour

Start the server and check for configuration warnings. Make a small, recognisable change in a safe test area, such as placing a labelled block arrangement. Allow the configured save period to pass during normal operation. Then perform a clean stop and start and confirm that the change persists.

That restart check shows that the world can save and load; it does not prove the maximum loss after a power failure, because a clean stop also saves data. Do not deliberately crash a customer server to measure that boundary. Record save-related log messages where available and compare hitch timing under a similar workload.

Recover

Restore the original interval if the change increases pauses, produces warnings or fails to address the problem. Keep the before-and-after notes and a short profiler capture for support. If disk pressure or a stuck backup overlaps the pauses, investigate that storage problem separately. Never overwrite the current world with a backup merely to undo a configuration interval.

Reference

Paper world save settings. Bukkit autosave interval. Paper configuration inheritance and paths.