Mastodon Relay Drop in Activity: How to Diagnose

When a Mastodon relay you administer or subscribe to suddenly shows a drop in activity, your instance timeline may feel empty or slow. This often happens because the relay has lost its connection to remote instances, the relay server itself has a configuration error, or the relay has been rate-limited by other servers. This article explains how to identify the root cause of a Mastodon relay activity drop and restore normal federation flow.

Why a Mastodon Relay Activity Drops

A Mastodon relay is a server that redistributes public posts from one instance to all other instances subscribed to that relay. When activity drops, the relay is no longer pushing or pulling posts effectively. The root cause is almost always one of three things:

First, the relay server itself may have a network or software issue. The relay process may have stopped, the server may be overloaded, or the relay software (such as Pub-Relay) may have crashed. Second, your instance may have lost its subscription to the relay. This can happen if the relay was restarted, if the subscription key expired, or if an administrator accidentally removed the subscription. Third, remote instances may have blocked the relay or your instance, causing federation to stop. This is common when a relay pushes too much traffic or spam, triggering automatic rate limits or manual blocks.

Steps to Diagnose a Mastodon Relay Activity Drop

Follow these steps in order to isolate the problem. Each step gives you a specific piece of information about the relay’s health.

1. Check the Sidekiq queue for relay jobs
   Log in to your Mastodon instance and navigate to https://yourinstance.example.com/sidekiq. Look at the Queues tab for any queue named scheduler or default containing relay-related jobs. If you see jobs stuck in the Retries or Dead tabs with errors like Net::OpenTimeout or HTTP 429, the relay cannot connect to remote servers. Clear these jobs by clicking the Clear Retries button if they are not recoverable, but note that you must fix the underlying connection issue first.
2. Verify the relay subscription in Mastodon admin
   Go to Preferences > Administration > Relays. You will see a list of relays your instance is subscribed to. Look at the Status column. If the status is pending or failed, the subscription handshake was not completed. Click the Enable button to re-subscribe. If the status is active but activity is still low, proceed to the next step.
3. Test the relay endpoint directly
   Open a terminal on your Mastodon server and run curl -I https://relay.example.com/api/v1/instance. Replace relay.example.com with your relay’s actual domain. If you get a 200 OK response, the relay is reachable. If you get a timeout or 403 Forbidden, the relay may be blocking your server or is down. Also check the relay’s /health endpoint if available, such as curl https://relay.example.com/health.
4. Inspect the Mastodon logs for relay errors
   Run docker-compose logs -f --tail=100 web (or journalctl -u mastodon-web for non-Docker setups) and look for lines containing Relay or ActivityPub::DeliveryWorker. Errors like HTTP 410 Gone mean the remote instance no longer exists. Errors like HTTP 429 Too Many Requests mean the relay or your instance is being rate-limited. Reduce the relay’s push frequency or contact the remote instance admin.
5. Check if your instance is blocked by remote servers
   Use the Mastodon API to see blocks: curl https://yourinstance.example.com/api/v1/instance/peers lists known instances. Then check if the relay appears in that list. If the relay is missing, your instance may have been blocked by the relay or by other instances that the relay serves. You can also ask the relay admin to check their blocklist.

If the Mastodon Relay Still Shows Low Activity After Diagnosis

Relay subscription shows active but no content arrives

This usually means the relay is alive but no remote instances are pushing posts to it. The relay must have at least one upstream instance that is actively posting. If you are the relay admin, check the relay’s own subscription list. If you are a subscriber, ask the relay admin to verify that other instances are still connected.

Sidekiq shows recurring failures with HTTP 410 or 404

These errors indicate that the remote instance the relay was pushing to has been deleted or moved. The relay will continue to try delivery and fail, wasting resources. As a relay admin, remove the dead instance from the relay’s subscription list. As a subscriber, you cannot fix this directly, but you can report the dead instance to the relay admin.

Relay server itself is unreachable from your instance

If curl to the relay fails, the relay may be down for maintenance, its domain may have expired, or your server’s firewall may be blocking the connection. Check the relay’s status page or contact its admin. If you are the relay admin, restart the relay service and check the relay’s own Sidekiq or system logs.

Item	Subscribed Instance	Relay Admin
Primary symptom	Empty federated timeline	Relay shows zero incoming posts
First diagnostic step	Check Sidekiq relay jobs	Check relay health endpoint
Common fix	Re-enable relay subscription	Restart relay service
Escalation path	Contact relay admin	Check firewall and rate limits

You can now diagnose a drop in Mastodon relay activity by checking the Sidekiq queue, verifying the subscription status, testing the relay endpoint, and inspecting logs. If the relay is still quiet after these steps, contact the relay administrator with the specific error codes you found. For relay administrators, enabling verbose logging in the relay software and setting up uptime monitoring will catch these issues earlier.