Logs

Best practices

Structured logs are only useful if they are consistent. Use clear names, levels, and metadata from day one.

Use stable log file names

The name field becomes a log file in the dashboard. Prefer short, stable names:

• connections
• player-kills
• economy
• ox_inventory

Avoid random names per event. That creates hundreds of noisy files.

Pick the right level

• debug — noisy development detail
• info — normal gameplay / lifecycle events
• warn — unexpected but handled
• error — failures that need attention

Put IDs in fields, not only the message

{
  "name": "economy",
  "level": "info",
  "message": "Bank deposit",
  "playerSource": "32",
  "metadata": {
    "amount": 2500,
    "account": "bank",
    "resource": "qb-banking"
  }
}

Messages are for humans. Metadata and playerSource are for filters and alerts.

Batch when you can

POST /api/v1/logs accepts an array. Batching reduces HTTP chatter during busy events.

Protect the key

• Only put log keys on the server.
• Never ship cnf_log_ to NUI or clients.
• Rotate keys if a resource or config leaks.