Troubleshooting
Find help with sign-in, setup, connections, files, and server recovery.
Start from the failed boundary. Do not delete a database, rewrite a migration ledger, or create another mystery instance just because the first path is not understood.
Users: choose the failed step
You do not need infrastructure access to report a useful problem. Start with the client, the account you intended to use, the approximate time, and the visible error. Do not include credentials or private content.
| What you see | Safe next step | Who acts if it still fails |
|---|---|---|
| Server cannot be reached, or the identity is wrong | Confirm the full address with your administrator; see connection help. localhost means the device you are using | Administrator checks the Server and network; do not create another Server |
| Sign-in fails, PIN is forgotten, or recovery codes are lost | Follow the credential-specific recovery route | Server administrator or identity-provider administrator, depending on the failed credential |
| No Genie or no conversation to enter | Follow the first-hour empty-state steps | Administrator checks membership, capability, and model configuration |
| A Genie does not answer | Check the Room and intended recipient, then routing and targeting | Administrator checks model/provider availability after the recipient is confirmed |
| Browser or Terminal is missing or handoff fails | Check supported client, identity, and workstation prerequisites | Administrator checks capability; the computer's user checks its connection and permissions |
| Writer will not import or export | Check the supported action and format, and preserve the source file | Administrator investigates the specific failed operation; do not repeatedly overwrite the only copy |
| Mobile account deletion stops or local cleanup remains | Read the deletion state and recovery step | Follow the named ownership/custody action; do not repeat deletion after Server success |
| An action is denied | Read the requested action and scope; inspect security posture when available | Ask the administrator about the exact missing capability; do not turn off approvals |
Administrators and developers: preserve evidence
Administrators should identify the exact deployment profile or Railway launch before taking action. Compose diagnostics and Railway upgrade/recovery are different lifecycles. Keep their receipts and recovery material separate.
Developers should use a named, disposable environment for a reproduction; a user's account problem does not authorize a database reset or migration-ledger repair. Follow the Developer guide.
Share only the minimum reviewed evidence: client/version, approximate time, error code, operation, and a correlation ID when provided. Give the exact Server address privately to its administrator, not in a public issue. Exclude passwords, PINs, recovery codes, session tokens, claim links, provider keys, and private message or artifact contents.
User: connection or account trouble
Check your client connection first. Ask your Server administrator about Server-side failures; do not run administration or migration commands.
Administrator: the Server is unclaimed
Claim the intended deployed Server through its verified setup handoff.
Developer: a migration will not apply
Compare committed migration history with the database ledger before changing either.
Administrator: the Server is degraded or unreachable
Identify the profile, topology, setup state, and failed boundary before changing anything.
Administrator: an upgrade or restore failed
Preserve the recovery bundle and evidence, verify provenance, and recover deliberately.
Find another symptom
Search all public documentation and scenarios.