# Troubleshooting > The failures a self-hosted Weald relay actually produces, what each one looks like from the app, and the one thing support cannot do for you. Source: https://getweald.com/docs/self-hosting/troubleshooting Last modified: 2026-08-03 --- ## When it breaks Last updated 2026-08-03 Most failures on a self-hosted Weald relay are one of five things: DNS, port 80, a database or bucket the relay cannot reach, a bootstrap invite that expired, or a client refusing a plaintext connection. The readiness endpoint names which dependency failed in words instead of printing a stack trace. Start there. ## The relay will not start Check /readyz on the private listener first. It reports Postgres and object storage reachability separately, so a failure names which one. - Postgres unreachable is usually a connection string that names a host the container cannot resolve, or a database that has not finished starting on a first boot. - Object storage unreachable on the compose path is the storage container failing its own start. On a bare binary it is a bucket name, a region or a credential. ## No certificate The bundle needs port 80 reachable to complete a challenge. A closed port 80 produces a relay that answers on no port at all, and the failure is reported as a certificate issuance failure rather than as an obscure ACME error. Two other causes, in order of how often they happen: the DNS record points at a different address than the host actually has, and the hostname in the environment file does not match the name in DNS. ## The client will not connect *What the app says, and what it means* | The app reports | Cause | | --- | --- | | Refused a plaintext connection | The relay is not serving TLS, or a proxy in front of it is not | | Hostname does not resolve | DNS, or a private network the client is not on | | Protocol version unsupported | The relay and the app are too far apart. Upgrade the older one | | Not in the access set | The device was revoked, or was never enrolled in this workspace | A relay reached over plaintext is refused rather than downgraded. The app tells you what happened instead of connecting anyway. ## The bootstrap invite expired The enrollment URL is single use and lasts twenty-four hours. While the workspace still has no trust root, the relay can reissue one; once a first device has enrolled, it refuses permanently and there is no support path around that. If a workspace has a trust root and nobody can reach it, the answer is the recovery phrase. If the phrase is also gone, the workspace is gone. ## Storage is growing and will not stop Storage falls when a workspace compacts, which is a control in the Mac app. A relay cannot compact on its own, because compaction is a decision about which history to drop and the relay cannot read history. A workspace whose admin devices stay offline accumulates uncompacted history, and nothing on the server side fixes that. If storage is climbing with no matching activity, check that an admin device has been online recently. ## A member sees a warning nobody else sees Two warnings cannot be muted, and both are worth stopping for. - A roster change the member did not perform. Somebody was added or removed, and the client is saying so. - A split view or transparency warning, which means two clients disagree about the history of a group, or one has gone silent when it should have spoken. Neither is a bug report. The right response is to compare safety numbers on two devices and read the transparency log. ## What support cannot do Support cannot read a workspace, cannot list its members, and cannot recover a lost recovery phrase. The diagnostic bundle the client produces carries versions, sync state, connection history and error logs, with content excluded and the exclusion visible before it is sent. Support covers what to send and where to send it.