FiveM Refund SOP for Lost Items After Server Crashes Using Discord Timelines

Server crashes happen even on well-maintained FiveM stacks. The real problem starts after the restart: players report missing weapons, cash, crafted items, or vehicle upgrades, and staff members handle refunds inconsistently. A crash-specific SOP (standard operating procedure) prevents arguments, protects your economy, and reduces staff burnout. This guide explains a timeline-based workflow using Discord tickets, roles, and log evidence so your team can verify “what happened” and issue consistent outcomes.

Scope and refund policy: define what you will and won’t replace

Write the policy for crash-related loss only, not general “I lost my item” cases. Your goal is to reimburse losses caused by a confirmed server incident, without creating a loophole for duplication or market manipulation. Keep it short enough that staff can apply it quickly and players can understand it.

• Eligible: items/currency removed due to a confirmed crash or forced restart window (example: inventory not saved after txAdmin restart).
• Not eligible: losses from PvP, scamming, voluntary drops, stash transfers, or disconnects unrelated to the incident.
• Time limit: claims must be opened within 24 hours of the incident (or your next scheduled staff shift).
• Cap rules: set a maximum reimbursement per incident (example: one weapon + ammo, or up to $50,000 in dirty money) unless an Admin approves.
• One claim per player per incident: merge duplicates to one ticket to avoid conflicting decisions.

Discord roles, permissions, and channels for a clean workflow

A timeline approach only works if evidence stays organized and access is controlled. Set up Discord so players can submit claims without seeing other players’ data, while staff can collaborate and audit decisions later.

• Roles: @Support (triage), @Refund Team (decision + payout), @Admin (overrides), @DevOps (crash verification).
• Channel structure: #status-incidents (read-only), #refund-sop (read-only policy), #refund-audit-log (staff-only), plus ticket channels created per claim.
• Permissions: players can only view their ticket; @Refund Team can view/send; @Support can tag and request evidence; @Admin can close with final reason.
• Bot permissions: allow the ticket bot to manage channels/threads, post embeds, and log transcript exports to a staff-only archive.

If you use a ticket bot (commonly Ticket Tool, TicketsBot, or a custom bot), configure a “Crash Refund” panel that collects structured fields: character name, Steam/Discord ID, approximate time of loss, what was lost, and the incident ID. Structured intake reduces back-and-forth and makes timeline reconstruction faster.

Crash detection and timeline anchors (txAdmin + server logs)

Your SOP needs a single source of truth for “when the crash happened.” Use txAdmin (or your host’s panel) as the primary anchor, then correlate with server logs and resource logs. The refund decision should start with confirming the incident window, not with the player’s story.

1. Create an incident post in #status-incidents as soon as staff confirms instability: include start time, restart time, and incident ID.
2. Export or screenshot txAdmin event details: restart reason, crash loop notes, and timestamps.
3. Pull server console logs around the window (example: 10 minutes before to 20 minutes after). Look for resource errors, MySQL timeouts, or save failures.
4. Identify the save cadence of your framework: ESX save intervals, QBCore player unload events, ox_inventory save triggers, and whether the crash interrupted them.
5. Mark the “risk window” in minutes (example: 23:14–23:22 UTC). Only reimburse losses that plausibly occurred inside this window unless Admin approves.

Example: txAdmin shows a watchdog restart at 23:18 UTC. Your console log shows repeated MySQL “Lost connection to server during query” at 23:16–23:18, and ox_inventory reports “failed to save player inventory” for several identifiers. That combination strongly supports crash-related loss and narrows the timeline for valid claims.

Ticket intake: build a Discord timeline from player and system evidence

In each ticket, your staff should reconstruct a timeline with at least three anchors: (1) incident window, (2) last confirmed possession, and (3) first confirmed absence. Discord is useful here because it stores timestamps, attachments, and message context in one place.

• Player evidence: a clip (Medal/ShadowPlay), screenshot of inventory UI, or a phone photo showing the item before the crash with a visible time; last purchase/craft message; bank transaction screenshot if relevant.
• System evidence: framework logs (ESX/QBCore), ox_inventory logs, shop logs, crafting logs, vehicle upgrade logs, and admin action logs.
• Discord evidence: messages in #status-incidents acknowledging the crash, and the ticket’s creation time relative to the incident window.
• Identity confirmation: match Discord ID to in-game identifiers (license:, steam:, discord:) and character name to avoid “wrong character” refunds.

Concrete example: A player claims they lost a “WEAPON_CARBINERIFLE” and 120 rounds after a crash. In the ticket, they provide a 30-second clip showing the weapon in their hotbar at 23:15 UTC. Your shop log shows a purchase at 23:12 UTC for that identifier. After the restart at 23:18 UTC, ox_inventory log shows the player loaded with no rifle. That gives you a tight timeline: possessed before crash, absent after restart, and a system record of acquisition.

Decision rules and payout methods (minimize abuse and economy impact)

A good refund SOP is predictable. Staff should not negotiate outcomes in tickets. Use decision rules that map evidence quality to a specific action, and prefer restoration methods that are auditable and hard to exploit.

1. Verify incident match: the loss must fall inside the risk window or have explicit Admin approval.
2. Score evidence: (A) logs + clip/screenshot, (B) logs only, (C) player media only, (D) no evidence. Define outcomes per tier.
3. Choose restoration method: prefer direct item grant via admin command or framework function with logging; avoid cash when the lost asset was an item.
4. Record the action: staff member, time, item, quantity, character identifier, and incident ID in #refund-audit-log.
5. Close with a reason code: APPROVED-A, APPROVED-B, DENIED-NO-INCIDENT, DENIED-INSUFFICIENT, or ESCALATED-ADMIN.

FiveM examples of auditable payouts: using QBCore’s add item functions, ESX inventory add functions, or ox_inventory exports, with server-side logging enabled. If you must reimburse money, prefer bank transfers over cash drops and log the transaction (who initiated it, amount, and reason). If your community uses a refund workflow tool like LD Refund System, keep it aligned with the same evidence tiers and incident IDs so staff decisions stay consistent across shifts.

Audit, retention, and post-incident improvements

Refunds are support work, but they’re also operational data. If you keep clean records, you can identify patterns: which resources fail to save, which restarts cause the most claims, and whether specific items are commonly abused in refund requests.

• Retention: store ticket transcripts and key attachments for 30–90 days (match your privacy policy).
• Metrics: number of claims per incident, approval rate by evidence tier, average resolution time, and top refunded items.
• Abuse signals: repeated claims across incidents, inconsistent identifiers, or media with missing timestamps.
• Technical follow-ups: adjust save intervals, add retry logic for DB writes, enable additional inventory/shop logging, and review resources that throw errors near crash times.
• Staff review: run a short after-action review in staff chat and update the SOP when you find edge cases.

Close the loop publicly in #status-incidents: confirm the incident is resolved, summarize what players should do if they were affected, and restate the deadline for crash refunds. That single message reduces duplicate tickets and sets expectations. If you use LD Refund System or a similar workflow, link the ticket entry point and remind players to include the incident ID and approximate time so staff can rebuild the timeline quickly.