How to Choose a Reliable Public Mastodon Relay

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. Add the relay to your Mastodon instance
   On your Mastodon server, edit the configuration file .env.production and add the relay URL under the RELAY setting. The format is RELAY=https://relay.example.com/inbox. Then restart Mastodon services with systemctl restart mastodon-. Verify the connection by checking the admin dashboard under Administration > Relays.
6. 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 the RELAY line 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.