Rust server lag: diagnose server FPS, memory and network trouble

By Niko Catarino

Updated 15 September 2026

A door takes seconds to open for everyone, or one player’s screen freezes while the rest keep playing. Both complaints sound like Rust lag. Start by finding out who was affected and what stopped responding.

Capture server FPS, client FPS and network symptoms at the same time. Ping can stay low while the server struggles to process actions or a player’s PC struggles to draw the scene. If you suspect a plugin, you will need to identify its work rather than count the installed plugins.

Note the time and duration before changing anything. The checks below apply to Rust PC dedicated servers; Rust Console Edition uses a different setup.

Identify which part is slowing down

Observation	First check
Several players see delayed actions or movement together	Match their timestamps with server FPS and process graphs.
One player’s view stutters while others play	Check client FPS and the local connection, then compare another client in the same scene.
Ping rises or players disconnect while server FPS holds its usual reading	Compare player connection records with the host’s traffic logs.
A stall repeats near a save, backup or plugin event	Match task duration and storage activity to the log timestamps.
An update preceded the problem	Check the installed Rust, framework and plugin versions against new errors and release notes.

Scroll to see all columns →

Record how long the stall lasts. A brief freeze can happen between graph samples, and two causes can affect the same session.

Read FPS in the correct console

Run this in the server console or authenticated RCON console:

fps

For the player’s client performance and ping, use the player’s F1 console:

perf 4

Hide that overlay after the test with perf 0. The displayed memory belongs to the client process; use your hosting panel or OS monitor for the Rust server’s memory. Facepunch console command reference

Note the server FPS cap and leave it at its current value. Compare readings during similar activity on this server. Raising the cap or adjusting tick-related settings now would change the conditions before you have found the fault.

Capture one incident before changing settings

Ask players for a time, time zone and description of the delay. “Door interaction took several seconds” gives you an action to investigate; “lag again” leaves that unclear.

Incident time / time zone / duration:
Affected players or regions / exact symptom:
Rust build / framework / plugins changed since last good run:
Map / save age / active players / activity:
Server FPS / existing FPS cap:
Rust process memory / allocation / CPU graph:
Client FPS / ping / connection observations:
Save, backup or scheduled-event timestamps:
Relevant error / first occurrence / repetition:
Change tested / repeat result / rollback:

Use panel logs and graphs first on managed hosting. If they show a machine-wide average, ask the host for Rust process or per-core readings. Keep the graph labels and sampling intervals with your record. Before posting logs in public, remove player identifiers, IP addresses, passwords and tokens.

Check memory pressure and server work

Compare the process-memory reading with Rust’s allocation. At the stall’s timestamp, look for paging, reported memory-limit terminations or repeated allocation warnings. High memory use needs that context before you can decide whether more RAM will help.

Check process and per-core CPU against player activity and the FPS drop. One busy core can be hidden inside a modest machine-wide average. Use the workload sheet in the Rust requirements guide if those readings suggest testing a different allocation.

Where the panel provides an entity count, record it with the save age and recent world changes. Keep the world intact while investigating. Deleting entities, replacing the map and removing plugins in one go would leave you unable to tell which change affected the stall.

If the lag began after a Rust update

Record the last working build and the first build that showed the fault. Check framework support for your Rust release, then plugin dependencies and changelogs. Capture the first repeating error, since later failures may result from it.

Repeat old measurements after changes to the game. Facepunch’s August 2026 update included changes to entity saving and memory pools, which can affect comparisons used to size a server. Facepunch: Power Trip

Before changing versions, back up the world, configs and plugin data and prepare a separate test instance. An older build may fail to read a newer save or accept current clients. Leave anti-cheat and admission controls enabled on the public service.

Test one suspected plugin without risking the live world

If the same scheduled plugin event precedes the stalls, reproduce it on a test copy:

1. Back up the world, plugin data and configuration outside the live service. Set up a restricted test instance with separate credentials. Replace or disable its copied live database, webhook and integration connections before startup.
2. Make a reference recording of the event using the same build, map, plugin versions, FPS cap and player activity.
3. Read the author’s settings and dependency requirements. On the test copy, disable the suspect event or change one supported setting.
4. Repeat the activity and take the same measurements. If the test remains safe, put the setting back and run it once more.
5. Check whether the stall disappears with the change and returns with the old setting. That gives the plugin author a fault they can try to reproduce. If the result does not repeat, keep investigating before assigning a cause.

Stop and restore the saved configuration and data if the test alters player data, breaks a dependency or makes the fault worse. Do broad plugin-disabling tests on the isolated copy. Keep whitelist, security and protection controls active on the public server.

Use a profiler when the graphs cannot explain the stall

A profile can show a developer which code consumes time or memory. Ask your host or plugin author what to capture. Facepunch provides a server profiler, and Carbon’s profiler covers game and plugin code. Facepunch profiler, Carbon profiler

Both profilers add work while recording. Agree on a capture duration and run it on the test instance or during maintenance. Finish the capture before another recording or settings change, then remove the profiling setup. Keep those diagnostic timings separate from measurements of normal play.

Follow the network evidence when server FPS holds steady

Use the Rust server-list checks if the browser entry disappears. Test listing access alongside gameplay; they use different services.

Compare players who had the fault with players who did not during that interval. Note their regions, client ping and whether they see the same problem on another server. A player can also test a wired connection or pause uploads, recording each change.

Give the host your timestamps and ask it to check packet loss, traffic and connection events. A ping or query reply samples one part of that route. A timeout needs investigation before being called an attack. If the host confirms attack traffic, keep the relevant timestamps and follow its mitigation process with protection enabled.

Decide whether the fix requires different hosting

Send a repeating plugin error to its author, or use its configuration guidance to test a remedy. For a memory-limit event, ask the provider to review the allocation. Ask it to address any host-side CPU or network constraint shown by the records. Retain the original test setup so you can compare the proposed fix with the existing service.

VYKIX managed Rust hosting gives you game-file access and Oxide/uMod and Carbon workflows. Send the incident record and workload details when asking us to assess a hosting change. A plugin fault still needs repair even if you move to different hardware or protection.

You can run a defined test during the 48-hour Rust trial. It requires a valid card, with no trial charge or automatic paid subscription. Trial hardware can differ from the paid plan. Export needed files before expiry: service is suspended after 48 hours, and active trial data is deleted seven calendar days after suspension. Continuing needs a separate paid order.

Review the Rust hosting configuration and trial terms, or use the Rust cost calculator to compare quotes for the configurations you want to test.