Troubleshooting a client

It will not start

Symptom	Cause	Fix
Start is refused immediately	No free plan slot	Stop another client, add a slot pack, or move up a plan. See starting and stopping
no account attached on the row	No account	Click it on the row and pick one. See accounts
Fails before connecting, version named	Game version above 26.1	Pin a supported one. See versions
dedicated IP is unreachable	Dedicated IP unreachable	Swap dedicated IP, or clear it to use the shared IPs. See dead dedicated IPs
Shared IPs are limited to … per account	Too many clients on the shared IPs	Stop one of them, or attach a dedicated IP
flow needs values that are not set yet	A required variable is empty	Fill in the values. See variables

It connects, then gets kicked

Immediately, every time. The server is rejecting the account. An offline-mode account on a premium-only server, or the reverse, is the usual cause. See add an account.

After a few seconds, repeatedly. Often a login plugin timing out. Add an auto-login flow, and keep the wait before the command. See recipes.

After a few minutes of no activity. The server does not allow idle players and kicks them. That is the server's rule: run the client somewhere that allows it, or only while you need it. See staying online.

When another client joins. The server limits how many connections it accepts, often per account or per address. Check its rules before running more than one client there.

It is online but does nothing

Almost always the flow, not the client. In order:

1. Is a flow attached to this client? The row says no flow attached when not.
2. Is that flow enabled? A disabled flow shows OFF.
3. Can its trigger fire? A when run manually or by webhook hat never fires by itself.
4. Are the action blocks actually under a trigger? Blocks left floating are dropped on save, which is the single most common cause. See how flows work.

Is my flow actually working? covers the rest, including how to read the run and error counts.

A chat trigger never fires

Turn on Verbose debug logging in the client's settings (it can be switched on while the client runs) and watch the console. Every incoming chat line then prints what happened to it:

• MATCH … speaker="Steve": it fired.
• SKIP (sender) … speaker="Bob" allowlist=[Steve]: the line came from someone who is not on the trigger's player list.
• SKIP (filter) … filter=/^!buy/: the filter did not match. Filters are tested against the whole rendered line, prefix and rank included, and they are case-sensitive: ^!buy never matches <Steve> !buy because the line starts with the prefix. Write !buy, or (?i)!buy to ignore case.

Even with the switch off, a trigger that has seen chat and matched none of it says so in the console after a minute, naming the gate that rejected the lines.

If the console shows no player from this server at the start of the line, the sender cannot be identified: chat relayed from Discord or another server carries a name nobody here is holding. Match on the text with a filter instead of a player list.

A flow half-works

Add a flow error trigger to be told what failed:

Then check the usual suspects: a container action with no window open, a dig on a block out of reach, a sleep attempted during the day, or a variable nobody filled in.

It keeps reconnecting

reconnecting in a loop means it connects and is dropped again. Look at the Errors filter on the console for the kick reason. The server usually says why. If the server is simply down, auto-reconnect keeps trying with backoff for a while, then gives up; with auto-restart on, the client is started again after that.

To stop it retrying while you investigate, turn off auto-restart on crash and stop the client.

A flow is running hotter than you expected

Running a flow costs nothing (the client's plan slot covers everything it does), but a tight loop with no wait sends the server far more than it needs. Add a wait inside every loop, and check the client's console to see how often the trigger is firing.