Minecraft Event Timers: What Happens When TPS Drops?

For a Minecraft event timer, first agree what makes time advance: server ticks, elapsed real time or an organiser-controlled pause. If a deadline must follow real time, the plugin should calculate the remaining duration from its chosen clock instead of subtracting one second whenever a repeating task runs. Then test lag, pauses and recovery before accepting the delivery.

This is a commissioning checklist for an event plugin on Paper. It gives an illustrative round specification, not a tested implementation. It is useful when a creator series or tournament must coordinate gameplay with a production schedule and staff need a clear rule for interruptions.

Decide what “five minutes” means

Paper's scheduler uses ticks. Its documentation shows why a tick delay takes longer when TPS falls; it also warns that moving a task off the main thread does not make world access safe. See the Paper scheduling guide.

Consider an illustrative 6,000-tick round. At a constant 20 TPS, it lasts 300 seconds; at a constant 10 TPS, 600 seconds. These are arithmetic examples, not server measurements. Whether that extension is acceptable depends on the event rules. A producer expecting a fixed broadcast slot may disagree with a game designer who wants a fixed amount of simulated play.

Write the rule before selecting a timer library:

Event requirement	Rule to agree
The round advances with game simulation	Count ticks; explain that real duration can increase.
Registration closes at a published instant	Store an absolute deadline and define which clock is authoritative.
A round lasts five real minutes, excluding staff pauses	Measure elapsed time and record explicit pause/resume transitions.

Do not use “real time” as shorthand for “no interruptions”. Decide separately whether downtime consumes the remaining duration and whether severe lag requires a referee to pause or invalidate the round.

Separate the display from the decision

A scoreboard is a view of the timer, not the timer's authority. Request one authoritative round state that staff commands, the display and gameplay checks all consult. Refreshing the display less often should not silently lengthen the round.

For a fixed deadline, a useful design rule is: remaining time equals the deadline minus the current time, with the displayed value bounded at zero. The developer still needs to specify the clock, rounding and how the result reaches gameplay safely. A value rounded down to zero must not close a round before its actual deadline.

Suppose a display update arrives late. It should show the current remaining duration, rather than replay every missed second. Decide which announcements may be skipped. A delayed “ten seconds left” message after the round has closed is misleading even if its scheduled task eventually runs.

Also require the submission or scoring handler to consult the authoritative state and time. A late end-of-round callback must not be the only barrier preventing a new action after the cutoff. Specify whether eligibility uses the time the server processes the action; accepting a client-supplied timestamp would require a separate trust design.

Choose a restart policy deliberately

Java's System.nanoTime() measures elapsed time within a JVM; it is not a calendar timestamp to reuse after restarting. This distinction is documented in the Java System API.

Ask the developer what is saved: the round identifier, lifecycle state and the timing information needed by the agreed recovery policy. Persisting only the number currently shown on the scoreboard leaves important questions unanswered.

For a deadline that continues through downtime, an absolute timestamp can support recovery. Specify the time standard and how clock corrections are handled. For a paused recovery, staff may instead need a saved remaining duration and explicit approval to resume. State how much timing information an abrupt crash can lose; do not assume a periodic save captures the final instant.

Neither policy restores a fair match automatically. If participants missed part of a competitive round, the organiser must decide whether to resume, cancel or replay it. The software should expose that choice without silently inventing extra playing time.

Work through one production example

Imagine registration closes at a recorded UTC instant. The countdown is informative, and the registration handler checks the cutoff before accepting each request. After a restart beyond that instant, registration stays closed. Staff can extend it only through an authorised change that records a new deadline and the reason.

Give each revision an identifier. A callback scheduled for an earlier deadline must check that it still belongs to the active revision before changing the state. Otherwise, an old task could close registration after staff have deliberately extended it. Test this exact sequence instead of demonstrating the original countdown alone.

No clock can make a stalled server process gameplay immediately. Agree how lateness is exposed and what staff do when the event cannot continue reliably. A deadline calculation prevents countdown drift; it does not provide an availability or response-time guarantee.

Require evidence from an isolated rehearsal

Add the following proposed checks to the plugin acceptance criteria. They have not been run for this article. Use a test environment and controlled clock or scheduling tests; do not disrupt a live event to manufacture lag.

1. Run normally and compare the intended deadline, displayed countdown and actual state transition.
2. Delay timer execution. Verify that the real-time policy does not add the missed interval to the round.
3. Process a new request after the cutoff but before a delayed closing callback. Verify rejection under the agreed rule.
4. Pause and resume. Confirm that only the agreed paused interval is excluded.
5. Restart before and after expiry, including an abrupt-stop scenario where agreed. Check the documented recovery and data-loss boundary.
6. Extend or cancel a round while an older task remains pending. Confirm that the stale task cannot reverse the new state.
7. Simulate a clock correction in the test clock. Record the expected result and compare it with the implementation.

Keep release versions, round identifiers, clock policy, expected outcomes and observed timestamps with the results. Agree acceptable lateness for the actual event; this checklist supplies no universal threshold. Include the staff display and recovery steps in the technical event rehearsal.

When commissioning custom Minecraft development, bring the round rules, production schedule, interruption policy and acceptance cases. Mineando scopes and quotes paid projects individually; maintenance and live coverage are agreed separately.