How to Verify a Mastodon Relay Is Actually Forwarding Posts

You added a relay to your Mastodon instance to boost visibility and bring in posts from other servers. But your local timeline remains quiet, and you are not sure if the relay is actually working. A relay is a server that acts as a middleman, forwarding public posts from one instance to another. This article explains how to test whether a relay is actively forwarding content to your instance and what to do if it is not.

Relays replace the older, less efficient “follow all users” approach. They let your instance subscribe to a relay server, which then pushes public posts from all member instances to yours. However, a relay can fail silently due to misconfiguration, network blocks, or the relay itself being offline. You need to check both the relay status on your server and the actual post flow on your local timeline.

This guide covers the exact steps to inspect relay connections via the Mastodon admin interface, verify post delivery using the web interface and server logs, and resolve common relay failures. By the end, you will be able to confirm if your relay is forwarding posts or if you need to replace or reconfigure it.

What a Mastodon Relay Does and Why It Can Fail

A Mastodon relay is a specialized server that collects public posts from all instances subscribed to it and redistributes those posts to every other subscribing instance. When your instance joins a relay, you do not need to manually follow users on each remote instance. Instead, the relay handles the bulk distribution. This is especially useful for small instances that want to stay connected to the wider fediverse without managing thousands of individual follows.

The relay uses the Mastodon ActivityPub subscription mechanism. Your instance sends a follow request to the relay server. The relay accepts that request and then sends your instance every new public post from all its member instances. The relay itself does not store posts permanently. It only forwards them in real time.

A relay can stop forwarding posts for several reasons:

Relay Server Is Offline or Overloaded

The relay server may be down for maintenance, rate-limited, or blocked by your hosting provider. When the relay is unreachable, your instance cannot receive forwarded posts. The admin interface will show the relay as “Disabled” or “Pending.”

Instance Configuration Error

Your instance must have outbound federation enabled and the correct relay URL. A typo in the relay address or a missing trailing slash prevents the connection. Also, if your instance is set to private mode or has a restrictive allowlist, the relay handshake may be rejected.

Network or DNS Issues

If your server cannot resolve the relay’s domain name or if the relay’s IP address is blocked by a firewall, posts will not arrive. IPv6 misconfiguration can also cause silent failures because the relay may attempt an IPv6 connection that your instance does not support.

Steps to Verify a Mastodon Relay Is Forwarding Posts

Follow these steps in order. Each step gives you a different piece of evidence about the relay’s health.

1. Check the relay status in the Mastodon admin panel
   Log in to your Mastodon instance as an admin. Go to Preferences > Administration > Relays. You will see a list of relays your instance has joined. Each relay has a status label: Enabled means the relay is connected and working. Pending means the relay has not accepted your subscription yet. Disabled means the connection failed. If the status is Disabled, click the Enable button next to the relay to attempt reconnection.
2. Watch the federated timeline for new posts from relayed instances
   Open the Federated timeline (also called the local timeline on some interfaces) in your Mastodon web client. Refresh the page every 30 seconds for about five minutes. Look for posts from usernames that include an @ sign and a domain different from your own instance. Those are posts forwarded by the relay. If you see zero new remote posts after five minutes, the relay may not be forwarding anything.
3. Inspect server logs for relay activity
   SSH into your Mastodon server. Run the following command to search for relay-related log entries from the last hour: grep -i relay /var/log/mastodon/log | tail -50. Look for lines containing relay, forward, or subscribe. A healthy relay produces lines like INFO -- : Processing ActivityPub relay delivery. Errors such as Net::OpenTimeout or SSL_connect indicate connectivity problems.
4. Test the relay endpoint manually with curl
   On your server, run this curl command to see if the relay server responds: curl -I https://relay.example.com/inbox. Replace relay.example.com with your relay’s actual domain. A successful response returns HTTP status 200 or 202. A timeout or 404 means the relay is unreachable or misconfigured. If the relay is a known public relay like relay.fedibird.com, check its status page if one exists.
5. Create a test post on a remote instance and verify it arrives
   Ask a friend on another Mastodon instance that is also subscribed to the same relay to post a public message with a unique keyword like #relaytest2025. Then, on your instance, search for that hashtag using the search bar. If the post appears, the relay is forwarding content. If it does not appear after 10 minutes, the relay is not delivering that post to your instance.

If the Relay Still Does Not Forward Posts

When the above steps confirm that the relay is not forwarding, the problem is usually one of these specific issues. Check each one in order.

Relay Shows “Pending” Indefinitely

A pending status means your instance sent a follow request, but the relay has not accepted it. This often happens when the relay requires manual approval. Go to the relay’s website if available and look for an admin contact. Some public relays have a web form to approve new subscribers. Alternatively, remove the relay from Administration > Relays and re-add it using the exact URL provided by the relay operator.

Posts Arrive Only From Some Instances But Not Others

If you see posts from one remote instance but not another, the relay itself is working, but the missing instance may not be subscribed to the same relay. Check the relay’s member list if it is public. The missing instance may have left the relay or been removed. Your instance only receives posts from instances that are also subscribed to that relay.

Relay Works but Posts Are Delayed by Hours

Delays indicate that your instance’s sidekiq queue is backlogged. SSH into your server and run systemctl status mastodon-sidekiq. If the service shows a high number of jobs in the queue, the relay posts are waiting to be processed. Restart sidekiq with systemctl restart mastodon-sidekiq. Also check your server’s CPU and memory usage. A resource-starved instance cannot process incoming posts quickly.

Relay URL Was Entered Incorrectly

A common mistake is adding the relay’s main website URL instead of the specific inbox endpoint. The correct URL for most relays ends with /inbox. For example, https://relay.example.com/inbox. If you entered something like https://relay.example.com, the relay cannot accept your subscription. Remove the relay and re-add it with the full inbox URL.

Item	Working Relay	Failing Relay
Admin panel status	Enabled	Pending or Disabled
Federated timeline after 5 minutes	Shows new remote posts	No remote posts appear
Server log entries	Contains “relay delivery” lines	Contains timeout or SSL errors
curl test to relay inbox	HTTP 200 or 202	Timeout or HTTP 4xx/5xx
Test post from remote instance	Appears within 10 minutes	Does not appear

You can now confirm whether your Mastodon relay is actively forwarding posts or needs replacement. If the relay is working, your federated timeline will show a steady flow of public posts from other instances. If it is not working, check the relay status in the admin panel first, then verify the URL and network connectivity. For persistent failures, consider switching to a different public relay such as relay.fedi.network or relay.fedibird.com. A tip: set up a second relay as a backup so that if one fails, your instance still receives content from the other.