Real-Time Remote Monitoring for Satisfactory Dedicated Servers
You have a dedicated server running. You want to know if it's up, who's connected, and how the factory is producing without launching the game every time. Three layers solve this: the FicsitRemoteMonitoring mod for in-game telemetry, the FactoryGame server log for connection events, and a dashboard layer that visualizes both. This page walks through the setup that's become standard in the Satisfactory dedicated-server community in 2026.
The FicsitRemoteMonitoring mod
FicsitRemoteMonitoring (FRM) is the community-standard mod that exposes a JSON HTTP API for live factory metrics. It's installed server-side via SML or SMM. Once running, it listens on a configurable port (default 8080) and returns endpoints like:
/getFactory— All running buildings, production rates, efficiency/getPlayer— Connected players, position, inventory/getPower— Power grid stats per circuit/getTrains— Train positions, station status, routes/getStorage— All storage containers and contents/getSink— AWESOME Sink throughput/getPipes— Fluid network flow and pressure
Every endpoint returns JSON. That JSON is what your dashboard layer consumes.
Installing FRM on a dedicated server
- Connect to your server via the file manager / FTP.
- Locate the
FactoryGame/Mods/directory. - Drop the FRM .smod file there (download from ficsit.app).
- Edit
FactoryGame/Configs/FicsitRemoteMonitoring.cfgto set:{ "HTTPPort": 8080, "HTTPSPort": 8443, "EnableHTTPS": false, "BindIP": "0.0.0.0", "EnableCORS": true, "APIKey": "" } - Restart the dedicated server.
- Test:
curl http://your-server-ip:8080/getFactoryshould return JSON.
If you're running on managed hosting, ask whether port 8080 needs to be opened explicitly. Most hosts default-block non-game ports.
Security: don't expose the API publicly
The FRM API has read-only endpoints, but it does leak the factory layout, every player's inventory, and the storage contents. That's not a security catastrophe but it IS social engineering ammunition (someone joining your Discord and saying "I see you don't have aluminum yet, want help?"). Tighten access in one of three ways:
Option A: API key
Set APIKey in the FRM config to a random 32-char string. Every API call now requires the header X-API-Key: yourkey. Share the key only with your dashboard layer.
Option B: IP allowlist via firewall
Set the server firewall to only accept port 8080 from your home IP / VPN IP / dashboard server's IP. Drop everything else. This is more robust than the API key because it works even if the key leaks.
Option C: Reverse proxy with basic auth (advanced)
Put nginx or caddy in front of the FRM port, terminate TLS, add basic auth. This is the right answer if you want public web dashboard access.
Dashboard layer options
Grafana + Prometheus (self-hosted, free)
The most popular setup for groups with self-hosting experience:
- Run Prometheus on the server box (or any always-on machine).
- Use a small Python or Go scraper to convert FRM's JSON into Prometheus exposition format.
- Point Prometheus to scrape your scraper every 15s.
- Run Grafana, point it at Prometheus.
- Build dashboards for: per-machine production rates, power grid health, train schedule conformance, storage saturation.
This stack is overkill for casual groups but unbeatable for 100-hour-plus factories where understanding bottlenecks matters.
Pre-built web dashboards (drop-in)
Several community projects ship as Docker containers or static HTML/JS that consume FRM directly:
- Satisfactory Factory Dashboard (various community forks on Github)
- FRM-Web (the canonical companion web UI)
- Pioneer Dashboard apps for browsers
These deploy in 5-15 minutes vs the hours needed for a Grafana setup. Trade-off: fewer customization options.
Mobile apps (iOS / Android)
Several developers have shipped Satisfactory Manager-style apps for phones that connect to your FRM endpoint over your VPN or a tunnel:
- Satisfactory Manager (Android, in beta as of 2026-Q2)
- Pioneer Mobile dashboards
- Custom Tasker / Shortcuts widgets pulling from FRM JSON directly
Setup typically: install the app, paste your server URL + API key, the dashboard auto-discovers endpoints. Best for "is my factory still running?" checks during the workday.
What to actually monitor (the useful subset)
FRM exposes everything; you don't need everything. Start with these five panels and add more only when you find a question they don't answer:
- Server uptime + connected player count. The "is it alive" panel. Page or push when this goes wrong.
- Power grid health. Total available vs. consumed; flag when consumption hits 90%+. Power failure is the most common dedicated-server crisis.
- Item production rates for the chokepoints. Pick 3-5 items that bottleneck your tech progression (steel ingots in mid-game, plastic in late, supercomputers near endgame). Plot rate over time.
- Storage saturation. Containers at 100% block downstream production. Plot the % full of your top 10 containers.
- Train schedule conformance. Are trains arriving on time? If not, you have a network or signal problem worth debugging in-game.
Alerts (for the obsessive)
If you want to be pushed when something breaks:
- Server down for 5+ minutes. Discord webhook or ntfy alert.
- Power at 95%+. Slack / Discord webhook.
- Storage at 100% for 30+ minutes. Discord. Indicates a stuck conveyor or merge issue.
- Train not arrived at expected station in 2x normal time. Indicates derailment or signal failure.
Alertmanager (paired with Prometheus) or Grafana's built-in alerting both work. For simple cases, a cronjob hitting FRM and posting to a Discord webhook is enough.
The "I just want a status page" path
If you don't care about historical metrics and just want a single web page showing "server up, X players, factory making Y per minute," the lightest-weight option is a static HTML page that JavaScript-fetches your FRM endpoint every 30 seconds. Deploy it on GitHub Pages or Netlify. Total setup time: 30-45 minutes. Total ongoing cost: free.
Performance impact of running FRM on the server
FRM is mostly read-only against the simulation state, but it does add some CPU and memory overhead. On a busy factory:
- Memory: +50-100 MB constant.
- CPU: +2-5% on the single replication core (more if dashboard pollers hit it every second instead of every 15s).
- Network: negligible on the LAN side, but if you expose it publicly with active dashboards, expect 5-20 KB/s outbound to dashboard consumers.
If you're already CPU-pegged from a 100x grinder run or late-game mega-factory, throttle dashboard polling to every 30 seconds and reduce the number of endpoints you scrape.
Related guides
- SML headless modding
- Update mods on a dedicated server
- Read server logs
- Network quality CPU bottleneck
Supercraft Satisfactory hosting exposes a panel with built-in server health metrics (player count, uptime, restart history), so you don't have to wire up Grafana from scratch unless you want production-line analytics. Custom port forwarding is available for FRM and other mods. Plans from $7.99/mo.