Restart Safety: Making FiveM State Survive a Restart

The failure mode: state that only exists in memory

A Lua table in a running resource is memory, and memory is not survived by a restart — the instant the resource or the server process restarts, whatever lived only in that table is gone. A cooldown counting down from a duration held in a variable, a temporary boost, or a half-finished multi-step process all disappear the same way: not with an error, just silently, as if they'd never existed.

This is a different failure from the concurrency and validation problems our net-event security and economy stress-test guides cover — those are about a single moment being attacked or raced. Restart safety is about time: whether a fact your system created is still true after the process that created it has died and come back.

Stored due dates vs. in-memory timers

The fix pattern is to store an absolute point in time — a due date or timestamp — rather than counting down a duration in memory. A resource that stores "expires at 2026-09-02T14:00:00" can recompute the remaining time correctly after any restart, because the fact itself (when it expires) never depended on the process staying alive. A resource that only tracks "3600 seconds remaining" in a variable has no way to know how much of that duration had already elapsed the moment it comes back — it either resets the full duration or forgets the cooldown existed at all.

The practical rule: on resource start, anything time-based should be reconstructed by reading its stored due date back from the database, not re-initialized from a default.

In-flight transactions and graceful shutdown

The harder case is an operation that was mid-flight when the process died. A graceful shutdown handler gets a brief window to flush state before the server actually stops — but it's a convenience, not a safety mechanism, because a crash or a forced quit skips it entirely. The only pattern that survives both graceful and ungraceful termination is writing state as durable before the action is considered complete, so there's never a window where memory says "done" while storage still says "pending."

For a worked example of exactly this kind of test applied to money specifically, our economy stress-test guide covers the crash-test methodology in full — including our own published result for VF Banking: ten kill-mid-transfer cycles reconciling to zero drift (measured 2026-07-06). Restart safety is the same discipline generalized to every kind of durable state, not just balances.

What has to be durable — a checklist

• Due dates and cooldowns — bans, boosts, job cooldowns, anything with an expiry.
• Ownership and possession records — who holds a vehicle's keys, who's renting what.
• Balances and the transaction ledger behind them.
• In-progress multi-step processes — a delivery job partway through its route, a queued craft.
• Deliberately-transient state that should NOT survive — a temporary combat flag, a session-only lock — restart safety includes choosing correctly what resets, not just what doesn't.

Why this sits in the economy cluster

Restart safety, server-authoritative validation, and concurrency safety are three legs of the same standard: a system that computes correctly, verifies its inputs, and doesn't lose track of what it already did — including across the one event that happens to every server eventually, on purpose or otherwise: a restart.