FiveM Discord refund bot downtime playbook with queue pausing and catch-up

Refund handling in a FiveM Discord is an operational workflow, not a one-off task. When your refund bot has downtime—API issues, a broken token, a hosting outage, or Discord permission changes—refund requests keep coming. If you keep processing manually without a plan, you’ll lose auditability and increase chargeback risk. This playbook focuses on two goals: pause the queue cleanly and catch up without duplicating payouts or missing evidence.

Define “downtime” and trigger the playbook early

Treat downtime as any period where the bot cannot reliably: (1) create/advance refund tickets, (2) write logs, or (3) apply status changes (approved/denied/paid). Common FiveM community scenarios include: the bot can’t post in #refund-logs because “Send Messages” was removed; it can’t read ticket channels because “View Channel” was revoked on a category; or it fails to assign a “Refund Pending” role due to missing “Manage Roles.” Trigger the playbook when you see repeated command failures, missing log entries, or stalled ticket state transitions for more than 5–10 minutes.

Set a clear trigger owner. In most communities, that’s the Head of Support, Community Manager, or whoever owns the Discord integration. They should be the person who decides to pause the queue and posts the status update. Avoid “everyone fixes it” because it leads to partial changes and inconsistent permissions.

Pause the refund queue without losing requests

Queue pausing means: stop new refunds from entering the “processing” path while still capturing requests and evidence. The cleanest approach is to keep intake open but lock down processing actions. In Discord, you can do this with roles, channel permissions, and ticket panel configuration.

1. Flip the ticket panel to “Intake Only”: if you use a ticket bot (e.g., Ticket Tool) for /refund tickets, disable auto-assign to the Refund Team role and remove auto-pings temporarily.
2. Post a pinned downtime notice in the refund intake channel (e.g., #refund-requests) stating: expected delay, what users must include (order ID, Steam hex, screenshot), and that duplicate tickets will be merged.
3. Lock processing channels: in the refund category, deny @everyone “Send Messages” in channels like #refund-processing and allow only Staff. Keep intake channels open.
4. Freeze state changes: restrict who can apply status roles like “Refund Approved” or “Refund Paid” to a small group (e.g., Senior Support) until the bot recovers.
5. Create a catch-up marker: note the last ticket ID or timestamp that was successfully logged in #refund-logs so you know where to resume.

Communicate in Discord with roles, channels, and a single source of truth

During downtime, communication prevents ticket spam and staff drift. Use one status message as the source of truth and link to it everywhere. A practical setup: a #status or #announcements post for the community, and a #staff-ops post for internal instructions. Keep the language direct: what’s broken, what’s paused, what users should do, and when the next update is coming.

Use Discord roles to reduce noise. For example, remove the bot’s ability to mass-mention @RefundTeam while paused, and instead have one on-call role like @RefundOnCall. If you use a role-based workflow (e.g., “Refund Pending” assigned when a ticket is created), document that the role assignment may lag and that staff should not manually assign “Paid” without the required evidence attached.

• Community update example (in #announcements): “Refund bot is currently offline. Refund intake remains open; approvals and payouts are paused. Please submit one ticket with order ID + Steam hex + proof. Next update in 60 minutes.”
• Staff update example (in #staff-ops): “Do not mark any refunds as Paid. Collect evidence only. Use the ‘Downtime’ tag on tickets. Last good log entry: 2026-02-22 18:10 UTC.”
• Permission reminder: bot needs View Channel, Send Messages, Read Message History in ticket channels; Manage Roles if it assigns status roles; and Embed Links if it posts receipts/log embeds.

Preserve evidence and audit logs while the bot is down

Most refund disputes are evidence disputes. While the bot is down, your job is to keep every request tied to verifiable identifiers and keep logs immutable. In FiveM communities, that often means: Tebex/CFX order IDs, Steam hex (license identifier), Discord user ID, and screenshots of the purchase or in-game transaction. If refunds relate to in-game items (vehicles, priority queue, whitelisting), capture the relevant server-side evidence too: admin action logs, inventory logs, and any txAdmin notes.

If your workflow normally posts to #refund-logs, create a temporary manual log format in the same channel to avoid splitting history. Example message template for staff: “MANUAL LOG | Ticket #1842 | User: @name (ID 123…) | Order: TBX-12345 | Amount: $20 | Status: Intake only | Evidence: attached | Handler: @staff | Timestamp: …”. Keep it consistent so you can later reconcile with automated logs.

Fix the root cause fast: a targeted Discord/FiveM checklist

Don’t guess. Triage from the outside in: Discord permissions, bot health, hosting, and then application errors. Start by checking whether the bot is online and responding to a simple command (e.g., /ping) in a staff channel. If it’s online but failing in specific channels, it’s usually a permission or category override issue.

1. Check Discord status and API incidents: if Discord has an outage, focus on communication and evidence capture; don’t churn config changes.
2. Verify the bot’s role position: ensure the bot role sits above any roles it needs to assign (e.g., “Refund Pending,” “Refund Approved”).
3. Verify channel/category permissions: confirm View Channel, Send Messages, Read Message History, Attach Files (if it uploads receipts), and Manage Messages (if it edits status messages).
4. Confirm token and intents: if you recently rotated tokens or changed privileged intents (Server Members Intent), re-check the developer portal settings and your config.
5. Review recent changes: audit the last 24 hours of Discord audit log for role/permission edits; check deployment history if you self-host.
6. Inspect logs: if you have a log channel and application logs (stdout, pm2 logs, Docker logs), look for rate limits, missing permissions (HTTP 403), or invalid interaction responses.
7. Validate FiveM-side dependencies (if applicable): if refunds reference in-game events, ensure your server logging (txAdmin, resource logs) is still writing so evidence remains available.

If you use a dedicated refund workflow tool like LD Refund System, keep a copy of its required permission set and channel requirements in your internal docs. Most “bot downtime” in practice is a missing permission after a category restructure or a role reorder—both are preventable with a quick pre-change checklist.

Catch-up safely: dedupe, replay, and close the loop

Catch-up is where teams accidentally double-refund. Your rule: no payout without a single authoritative record that ties the user, order, and approval together. When the bot comes back, keep the queue paused for a short stabilization window (15–30 minutes) while you validate logs and permissions. Then process tickets in strict order using the marker you recorded earlier (last good log entry or timestamp).

• Dedupe method: search by order ID (e.g., TBX-12345) across open tickets and #refund-logs; merge duplicates into one ticket and note the merge in the log.
• Approval replay: if staff approved during downtime, require them to restate approval in the ticket with a checklist (order ID, reason, evidence link). Avoid “approved in DMs.”
• Payout sequencing: only one role (e.g., Senior Support) executes payouts; everyone else gathers evidence and prepares summaries.
• Close-out standard: when marking “Paid,” attach proof (transaction ID, screenshot, or receipt) and ensure the bot (or staff) posts a final log entry.
• Post-mortem note: record cause (permission change, hosting restart, token rotation) and the exact Discord audit log entry if relevant.

Once you’ve processed the backlog, unpause intake automation and restore normal role pings. Then post a brief resolution update: what happened (high level), what users should do if they’re still waiting (link to the intake channel), and the timeframe you covered (“All tickets submitted before 18:10 UTC have been processed”). This closes the loop and reduces repeat tickets.

Finally, convert the incident into prevention. Add a “refund workflow change” checklist to your Discord change management: before moving categories or editing roles, confirm the bot can still View Channel/Send Messages in ticket categories and can write to #refund-logs. If you maintain multiple bots (tickets + refunds + moderation), document which bot owns which step so staff don’t improvise under pressure.