Mastodon relays are servers that forward public posts between instances. When you connect your instance to a public relay, it receives boosts from all other instances linked to that relay. This can quickly fill your federated timeline with relevant content. However, not all public relays are reliable. Some are overloaded, poorly maintained, or shut down unexpectedly. This article explains what makes a relay reliable and how to evaluate one before connecting your instance.
Key Takeaways: Selecting a Mastodon Relay That Stays Online
- Relay uptime and maintainer reputation: Check the relay’s status page and the maintainer’s history with other projects before connecting.
- Relay moderation and content filtering: Choose a relay that filters out spam, illegal content, and excessive noise from large instances.
- Relay capacity and performance: Avoid relays that show high latency or frequent timeouts by testing with a small instance first.
What a Public Mastodon Relay Does and Why Reliability Matters
A Mastodon relay is a server that acts as a middleman between instances. When instance A posts a public status, the relay forwards it to instance B, instance C, and any other instance subscribed to that relay. This is different from direct federation, where each instance individually discovers and follows the other. Relays accelerate content distribution and help small instances discover posts from the wider Fediverse without manually following hundreds of users.
Reliability is critical because a relay that goes offline causes your instance to stop receiving updates from other relay participants. If the relay is poorly moderated, it can flood your timeline with spam or illegal content. A relay with high latency or frequent timeouts will degrade the user experience on your instance. Therefore, choosing a relay is not a trivial decision — it directly affects the quality of your federated timeline and the load on your server.
How a Relay Differs From Direct Federation
In direct federation, your instance must know the remote instance’s domain and follow it explicitly. Relays remove this requirement. When your instance subscribes to a relay, it tells the relay to send it all public posts from all other instances that also subscribe to that relay. This means your instance receives content from instances it has never contacted before. The tradeoff is that you lose control over which instances’ content appears in your timeline unless the relay applies filters.
Common Relay Failure Modes
Relays fail in three main ways. First, the relay server itself goes offline due to hardware failure, lack of funding, or the maintainer abandoning the project. Second, the relay becomes overloaded because too many instances are connected and the server cannot handle the message volume. Third, the relay does not moderate content, causing your instance to receive spam, hate speech, or illegal material that you must then manually block.
Steps to Evaluate and Connect to a Reliable Public Mastodon Relay
Follow these steps to find a relay that meets your instance’s needs. Perform each step before adding the relay to your instance configuration.
- Check the relay’s public status page
Most reliable relays publish a status page or a health endpoint. Visit the relay’s web address and look for a page that shows uptime, current load, and number of connected instances. If no status page exists, treat the relay as higher risk. - Review the maintainer’s reputation
Search the Fediverse for the relay’s domain name. Look for posts from other instance admins complaining about downtime, spam, or slow performance. Check if the maintainer runs other Fediverse services and how long those services have been online. - Verify content filtering and moderation policies
Read the relay’s documentation or about page. A reliable relay explicitly states what content it filters, such as media-only posts, posts from instances on blocklists, or posts containing certain keywords. If the relay has no moderation policy, it will likely pass spam to your instance. - Test the relay with a small instance first
If you run a large instance, create a test instance or use a spare domain to connect to the relay for a few days. Monitor the test instance’s CPU and memory usage, the rate of incoming posts, and the number of spam reports generated. If the relay causes high resource usage or spam, do not connect your main instance. - Add the relay to your Mastodon instance
On your Mastodon server, edit the configuration file.env.productionand add the relay URL under theRELAYsetting. The format isRELAY=https://relay.example.com/inbox. Then restart Mastodon services withsystemctl restart mastodon-. Verify the connection by checking the admin dashboard under Administration > Relays. - Monitor your instance after connecting
For the first week after connecting, check your server’s resource usage daily. Look at the federated timeline for unexpected content. If you see spam or illegal posts, disconnect the relay immediately by removing theRELAYline from your configuration and restarting Mastodon.
Common Issues When Using Public Mastodon Relays
Relay Sends Only Spam or Low-Quality Content
This happens when the relay does not filter content from instances that are known for spam or when the relay itself is compromised. To fix this, disconnect from the relay and switch to one that publishes a clear moderation policy. You can also run your own private relay that only connects to trusted instances.
Instance Performance Degrades After Connecting a Relay
A relay that forwards posts from many large instances can overwhelm your server’s Sidekiq workers. This causes delays in processing local posts and notifications. To fix this, reduce the number of relays you connect to, or limit the relay to only forward posts from instances with fewer than a certain number of users. Some relays allow you to set a maximum user count per instance.
Relay Stops Working After a Few Weeks
The maintainer may have abandoned the relay or the server may have run out of disk space or bandwidth. Check the relay’s status page for any announcements. If the relay is dead, remove it from your configuration and find a new one. To avoid this in the future, choose relays that have been online for at least six months and have a public funding or donation page.
| Item | Public Relay | Private Relay |
|---|---|---|
| Setup effort | Minimal — add one line to config | Requires installing relay software on your own server |
| Content control | Low — depends on relay’s moderation | High — you control which instances are allowed |
| Maintenance cost | None | Server resources, updates, and monitoring |
| Uptime risk | High — relay may shut down without notice | Low — you control uptime |
| Best for | Small instances wanting quick content discovery | Large or sensitive instances that need strict content filtering |
You now know how to evaluate a public Mastodon relay before connecting your instance. Start by checking the relay’s status page and moderation policies. Test the relay with a small instance first to avoid performance issues. For maximum control, consider running your own private relay with software like relay from the Mastodon ecosystem.