Your panel says the service is running, your friends are hammering refresh in the in-game server list, and your server isn't there. Or it's there and nobody can get in. Or it was fine yesterday and this morning half your community has lost their dinosaurs. Path of Titans servers fail in a fairly small number of ways (it's a shorter list than the panic suggests), and almost all of them trace back to one of four things: the auth token, the command line, the database mode, or a mod ID with a zero in it where there should be a letter O.
This is the guide we point people at when a ticket comes in. It's written for Path of Titans servers running with us, so the paths and the panel bits are ours. Log in at control.low.ms and open your service, and everything below will line up with what you're looking at. If you're moving a server in from somewhere else, Path of Titans Save Location & How to Upload Your World is the one you want first.
Two things worth knowing before you start, because they save a lot of wasted clicking. Path of Titans doesn't come from Steam, so Steam Update in the sidebar does nothing for it. And there's no Mod Manager entry for PoT either. Mods are a config file, and updates are a button of their own. Both are covered further down.
The server never turns up in the in-game browser
Nine times in ten this is the auth token, so start there and don't skip it.
Open Service Settings on your service. There's an Auth Token field, and it's the one setting the server genuinely cannot boot properly without. If it's empty, or if it's carrying a token you generated some time ago, that's your answer. Generate a fresh one at https://alderongames.com/oauth/hosting-token with the Alderon account that owns the game, paste it in, and save.
Then here's the part that catches people. Generating a new token revokes every token you generated before it. Alderon say so in their own hosting documentation, and it's the single most common cause of the "but it worked last week" ticket: nothing changed on the server, somebody just generated a token somewhere else. If you run more than one PoT server and you go and mint a fresh token for the new one, the old one stops authenticating the moment you do. Same token everywhere is fine. Minting a new one and only updating one server is not.
The token is handed to the server process when the process launches, which means saving it isn't enough on its own: you need a full stop and start. Restarting from the panel does that. Hitting save and waiting will not.
Once you've done that, a few sanity checks:
- There's a Set AuthToken button on your service page. It prints the token the server will actually use straight back to the console, so it's the fastest way to confirm the value really saved rather than silently truncating.
- Give it a few minutes. A freshly started server takes a little while to register with Alderon's network before it shows up for anyone, and people declare it broken well before that window is up.
- Watch Web Console or Log Viewer through a start. An authentication failure is loud, and it looks roughly like this:
LogTemp: Error: UAlderonEOS:OnLoginCallback: Failed to login
If you see that, the token is wrong, expired or revoked. Nothing else you change will help until it's replaced.
You don't need to open any ports. We assign them, and the server is launched bound to your service IP with the query listener on the game port plus one. If your game port is 7777 then your query port is 7778 and RCON is 7779, and none of that is yours to configure. You'll find guides elsewhere insisting the query port is the game port plus four: that's another host's layout, not ours, and following it will send you chasing a problem you don't have.
Players can see the server but can't get in
Different symptom, different causes. If it's listed and reachable-looking but connections bounce, work down this list.
Version mismatch is the usual culprit, and the giveaway is that some people get in and others don't. Alderon pushed an update, some clients have taken it and your server hasn't. The fix is the Update button on your service page, not Steam Update: Path of Titans installs through Alderon's own command-line tool, and the Update button is what drives it. It pulls whatever build your Branch setting points at. Which brings me to a related trap: if you've typed something into the Branch field that isn't a real branch, the update fails rather than falling back to production. Leave it alone unless Alderon have handed you a specific branch and a branch password to go with it.
Your password isn't where you think it is. The server password lives in Service Settings, not in Game.ini. The panel writes both the server name and the password into Game.ini from those fields, so editing the ServerName= or ServerPassword= lines in the file by hand is a waste of an afternoon. Set them in Service Settings and restart.
A stray whitelist entry locks the door. PathOfTitans\Saved\Whitelist.txt is a real file on your server and it's easy to forget you ever touched it. One Alderon ID in there and everybody else is refused. Same for Bans.txt: both take an Alderon ID like 525-053-709, one per line, and the format is unforgiving about stray characters.
Try direct connect. It's the cleanest way to split "not listed" from "not reachable". If direct connect with your IP and game port works but the browser listing times out, that's a server-list registration problem rather than a connectivity one, and it's worth a ticket so we can look at the -ServerListIP argument on your command line.
And check Current Activity & Stats for your actual player count before assuming anything clever. Full is full.
The server dies on startup
Open Log Viewer first. Path of Titans is reasonably honest about why it fell over, and the answer is nearly always sitting in the last fifty lines before the process exits.
The things that actually cause it, roughly in order:
A broken Game.ini. If you've been editing it in File Manager and the server stopped booting immediately afterwards, revert your last change. Commands.ini is the same story: it's the file that defines your admin roles and permissions, it runs to a couple of hundred lines, and one malformed +Permission= entry partway down can take the whole boot with it.
A mod that isn't ready for the current build. Strip the mod list back to empty, start, and confirm the server boots clean before you go looking anywhere else. The section below covers putting them back one at a time.
An update that half-landed. Run Update again and let it finish. It re-downloads Alderon's command-line tool each time, so a failed update usually just needs another go rather than anything clever.
Something genuinely corrupt. Take Cloud Restore or Backup Manager, pick the most recent snapshot from before the trouble started, and roll back, and grab a Cloud Backup first if there's anything since then you'd miss.
Worth knowing: the Game.ini we ship has bServerAutoRestart=false in it. If you want a scheduled restart, I'd use Scheduled Tasks in the panel rather than the in-game timer. It's visible, it's logged, and it doesn't quietly fight with anything else.
Characters and progress have gone missing
First, work out which database you're on, because the answer changes completely. Service Settings has a Database dropdown with two options, Local and Remote, and every server we run defaults to Local.
On Local, all your player data is files on your own server. Accounts sit in PathOfTitans\Saved\DatabaseCache\Account\ as JSON named by Alderon ID, and each dinosaur is its own JSON under PathOfTitans\Saved\DatabaseCache\Character\. That's the whole database. Zip that folder from File Manager and you've got a complete backup of every player and every creature on the server.
Alderon are blunt about the trade-off, and I think they're right to be: local database servers carry a real risk of losing player data to a crash or a bug. That's the price of owning your own data. It's also exactly why our automatic cloud backups matter more on PoT than on games that write one tidy save file: if characters vanish, Cloud Restore is your first move rather than your last.
On Remote, the data isn't yours at all. It's held by Alderon in their managed database, keyed to your server, and DatabaseCache will be empty or close to it. Restoring one of our backups won't bring characters back, because they were never in the backup in the first place.
Now, Alderon's current hosting documentation pushes the other way from our default, and it's worth knowing that before you decide anything. Their words: "It is highly recommended to use a Remote Database so that you can run multiple servers and have them share the same database. Also prevents data loss if you accidentally delete your server folder." Their older community-server wiki recommended the opposite, Local unless you were clustering. If you've read both and come away confused, that's why. Go by the newer page.
My own take is that neither is wrong, they just fail differently. Remote suits you if you run more than one server and want shared progression, or if you'd rather Alderon carried the risk than you. Local suits you if you want to be able to roll a bad day back, because a cloud backup can only ever restore data that actually lives on your server. Pick deliberately, and know which one you're on before something goes wrong rather than after.
Then there's the trap, and it's nastier than "nothing transfers automatically". Alderon spell out what happens in each direction, and the two are not symmetrical:
- Local to Remote: "The local database will be replaced, and existing local player data will be lost."
- Remote to Local: "The remote database remains unchanged, but the local database will start fresh."
Read that twice before you touch the dropdown, because it decides whether you can undo it. Remote to Local is recoverable. Your characters are still sitting with Alderon, so switching back brings them straight back and the empty server you just stared at was never the real thing. Local to Remote is not recoverable. The local database is replaced, and flipping the setting back will not conjure it up again.
Which means the instinct this section started with is the dangerous one. If characters have vanished and you're about to try the other database mode to see whether they turn up there, stop. On a Local server that single click is what turns a bad afternoon into a permanent loss. Take a Cloud Backup before you switch, always. If you've already switched and lost local data, a Cloud Restore to a snapshot from before the change is your only way back. Alderon have said migration tooling is on the way, but it isn't here yet, so today the switch is one-way in exactly the direction most people try first.
One more thing not to do: don't delete DatabaseCache to "clear something up". On a Local server that's every character, gone, with no undo beyond a backup.
Mods and modded maps won't load
There's no Mod Manager for Path of Titans in our panel and you're not missing a button. Mods are one config file.
Open PathOfTitans\Saved\Config\WindowsServer\GameUserSettings.ini in File Manager. Under the [PathOfTitans.Mods] header, one line per mod:
[PathOfTitans.Mods]
EnabledMods="UGC_M_DYV7XYEGX2_SK"
EnabledMods="UGC_M_DYV0XMY7GX_SK"
Mod IDs come from the in-game Mod Browser: open the mod's page in the game client and the ID is listed on it. Restart the server afterwards, because the list is only read at boot.
Then the two things that go wrong:
Zero versus the letter O. Alderon call this out specifically, and it's the single most common reason a mod ID silently does nothing at all. Those IDs contain the letter O. Copy them, don't retype them.
A modded map needs two entries, not one. Adding the map mod's ID to GameUserSettings.ini is only half the job. You also need ServerMap=MapName in Game.ini under [/Script/PathOfTitans.IGameSession], using the exact map name the mod specifies. Miss that and the server quietly boots Panjura instead, which is why "my mod map won't load" almost always turns out to be this one.
Which raises the stock maps, because they work differently and it trips people up. Your map comes from the command line. Commandline Manager carries a ready-made line for each one, and Gondwa is listed under its internal name Island, which is not remotely obvious. There's also a Map dropdown in Service Settings, and if the command line you're running names a map itself then the command line wins and that dropdown does nothing. So if you've changed the dropdown and the server keeps booting Panjura, there's your reason. Change it in Commandline Manager instead.
Last mod note: they can be genuinely slow to load. A server with several large mods, on its first boot after a change, will sit there for a while doing apparently nothing. Give it longer than feels reasonable before you decide it's hung, and watch Log Viewer rather than the clock.
Before you open a ticket
Genuinely, don't spend two hours on this. Open one from the panel and give us:
- What changed just before it broke: a mod, a setting, an update, a token.
- The last fifty lines from Log Viewer around the failure.
- Whether it's everyone or one specific player.
- Whether direct connect works when the browser listing doesn't.
That last pair answers half the question before we've even looked. We're around 24/7, and if it turns out to be something on our side we'll tell you what it was. If you're weighing up a bigger server while you're here, the plans are on the Path of Titans hosting page.