Rust Console Bot Stops Working After a Restart? How to Make It Auto-Reconnect

Why your bot goes silent after a restart

Your bot talks to your server over WebRCON, which is a live connection held open the whole time. When the server reboots for any reason, that connection drops. The game itself comes back fine and players reconnect on their own, but the bot's link is a socket that has to be reopened and re-authenticated from scratch. A bot with no auto-reconnect just holds a dead line. It can still look online in Discord while it is actually talking to nothing.

There is a common misconception worth clearing up first. On console there are no add-ons to install to keep a bot alive in the background, so reconnecting after a reboot is entirely the bot's own job, handled over WebRCON. If a guide tells you to install something server-side to fix this, you can ignore it, because on console there is nothing to install and the reconnect runs through your server settings and the bot.

The three restarts that catch every console owner

Almost every silent-bot report traces back to one of three reboots. First, the nightly host reboot. Many hosts restart the server on a schedule, often overnight, to keep it healthy. That is why the bot is dead at the same time every morning like clockwork.

Second, the weekly wipe. Rust Console servers usually wipe weekly, often Thursday around 18:00 UTC, or every two weeks. A wipe reboots the server, which drops the connection. Third, Facepunch update reboots. When a patch ships, G-Portal auto-updates and reboots the server for you, which is convenient but knocks the bot offline until it reconnects.

None of these are bugs. They are normal, and they will keep happening every week. That is exactly why this is really a question about reliability, not a one-off fault. If your bot goes dark after these events on a regular basis, what you actually have is a bot that keeps disconnecting, and the real answer is automatic recovery rather than a manual reconnect. It also helps to have a wipe day checklist so the reconnect is one less thing you think about on your busiest day.

Killfeed stopped after the wipe? The feed did not break

This is the single most common version of the problem. Your killfeed goes quiet right after wipe day and you assume the killfeed feature is broken. It almost never is. Kill events travel over the same WebRCON connection as everything else, so when the wipe reboots the server and the connection drops, the feed goes silent along with it. The moment the connection is restored, kills start coming through again.

There is a genuinely different case worth knowing about: the bot is connected, the light is green, and there is still no feed. That points at something other than a reboot, and it is worth reading up on why a bot can be connected but showing no killfeed. But if the feed died at the exact moment of a wipe or an update, treat it as a dropped connection first, not a broken feature.

You restarted in G-Portal and now commands do nothing

Here is the sequence that trips people up. You hit Restart in the G-Portal panel, the server bounces, and now the commands you send from the bot appear to do nothing at all. That is not the commands failing. Your bot's session is still pointed at a server that went away and came back, so every command is going down a dead line and landing nowhere.

The instinct is to resend the command five or ten times until something works. Do not. The fix is to get the bot to reconnect, at which point the very same commands work on the first try. This is one place where your host matters: Nitrado owners connect through a one-click account link, so there is no IP or port to babysit, while G-Portal is a direct WebRCON connection using your server IP, RCON port, and password. Either way, the cure for restart-then-nothing is reconnection, not repetition.

Why reconnecting by hand makes it worse

Rust briefly locks RCON after repeated failed authentication attempts. That single fact changes everything about how you should reconnect. If you spam the connect button or fire off retry after retry, you can trip that lockout, and now even a perfectly correct password gets refused for a short while. You have turned a two-minute reconnect into a ten-minute one.

If you are reconnecting manually, do it once and give it a moment. If it still will not authenticate, the problem is a detail, not the retry count, and it is worth reading how to clear an RCON authentication failed error before you try again. The most common culprit is a host that rotated your RCON password, or a password with special characters that never got copied cleanly in the first place.

What real auto-reconnect actually does

A bot that survives restarts is watching its own connection, not waiting for you to notice. When the socket drops, it should catch it within seconds. Then it should wait a beat and retry with a gentle backoff instead of hammering, which is what keeps it from ever tripping the RCON lockout. Next it re-authenticates itself using your stored credentials, and finally it picks the killfeed, alerts, and commands back up on its own. Done right, you never see the outage at all.

This is the core of what Vantic is built to do. It reconnects itself after every nightly host reboot, every weekly wipe, and every Facepunch update reboot, and it backs off politely rather than spamming retries, so it does not lock itself out of RCON. The point is not a fancier dashboard. The point is that you stop doing a manual reconnect every single morning and the server just runs.

Set your connection up so reconnect can succeed

Even flawless reconnect logic will fail if the underlying connection details are wrong, so it is worth getting these right once. Two things trip owners more than anything else. The first is the port. WebRCON uses your RCON port, commonly 28016, which is a TCP or WebSocket port, and that is a different number from the game port server.port, which is 28015 and runs on UDP. The classic symptom is that players can join fine but the bot cannot connect, which usually means the game port got entered where the RCON port belongs. Some hosts also need rcon.web set to 1 before WebRCON will answer at all. If any of that is unfamiliar, get clear on the RCON port versus the game port first.

The second is the password. A host-generated RCON password with special characters or spaces can break authentication if it is not copied exactly, and if your host rotates it, you have to update it in the bot. Get the IP, the correct RCON port, and the exact password lined up once, and a good bot will handle every reboot from then on. If you are still stuck at the very first connection and nothing will link up at all, the full walkthrough for when WebRCON will not connect covers the remaining edge cases.

Frequently asked questions

Keep reading

a bot that keeps disconnecting · connected but no killfeed · fixing RCON authentication failed · when WebRCON will not connect · a wipe day checklist