Detection · live

Server analytics

Server analytics is the always-on view of what's running on your server. It catalogs the loaded resources, scores each one into a risk bucket, and visualizes when triggers fire across the week. Findings stay alert-only — operators decide what to do with them.

What it protects against

The realistic threats here are slow-burn: a resource that drifts to a higher risk bucket after a vendor update, a hidden command surface that suddenly fires once a day at 3 AM, or trigger spam from a resource that's not supposed to be chatty. None of those show up in a snapshot — they show up in a 7-day pattern.

What we look at

  • Resource manifest — what the resource declares it loads, in what order, with which dependencies.
  • Static analysis of dangerous native usage — at the class level, never a published list. The score reflects how many high-privilege capability classes a resource touches, not which specific natives it called.
  • Trigger-event volume — how often the resource emits server events, aggregated per server and per resource.
  • Connect-pattern correlation — joins flagged by Anti-VPN are correlated with which resources were most recently active when the join arrived; that's how alt-cluster signals get a soft boost without becoming a hard ban trigger.

Risk buckets

Each loaded resource gets bucketed. The bucket is what the dashboard shows; the underlying score is intentionally not exposed (see Rule engine for why).

VerdictWhat it means
lowThe resource looks like a standard, well-behaved FiveM resource. No action recommended.
mediumThe resource carries one elevated signal (uses high-privilege natives, calls external endpoints, or shows unusual trigger volume). Worth a glance the next time you're in the dashboard.
highMultiple corroborating signals. Surfaces as an alert banner; manual review is recommended before continued use.

What's in the dashboard

  • Loaded resources — sortable, searchable table with the bucket and the short reason behind it. Collapsible for servers with hundreds of resources.
  • 7-day heatmap — weekday × hour, colored by trigger-event volume. Click a cell to drill into the per-day breakdown for that hour, including the top three contributing resources.
  • High-risk alert banner — appears at the top of the analytics tab when a resource crosses into the high bucket. Edge-triggered (only fires once per crossing), with a one-hour cooldown so it doesn't spam during noisy periods.
  • Resource blacklist editor (admin only) — define your own patterns (exact / substring / regex) with a risk level and a written reason. Soft-deletes remain visible in the audit log.

Cadence & latency

every 5 min
Resource snapshot
Off-path aggregation. Doesn't run on the connect path; doesn't move tick-rate.
30 s
Trigger aggregation flush
Trigger-event counters are buffered in memory and flushed to the analytics database every 30 seconds.
rolling 7 days
Heatmap window
The heatmap is always the last 7 days of trigger activity, refreshed on each tab open.
02:00 UTC
Daily cleanup
Retention follows Privacy Policy §9. Old aggregations are deleted automatically.

Methodology: measurements above are operating norms on a representative pilot server. Latency under load is dominated by your own resource count; we don't quote a single number because it's not honest at scale.

Operator recommendation

  • First week — open the analytics tab daily. The heatmap baseline becomes obvious after a few days; anomalies stand out fast once you have a feel for it.
  • Custom-resource-heavy stacks — expect to mark a handful of internal resources as trusted on the first run. Use the audit log as your changelog.
  • Alerts go to the team — wire the dashboard alert into your operator Discord (read-only channel). Don't put it in a public channel; the alert text wouldn't help an attacker, but it gives away an investigative pattern.