Mastodon federation allows users on different servers to follow each other and share posts. But sometimes you cannot tell if your instance is actually federating correctly with the rest of the fediverse. You might see an empty federated timeline or your posts never reach users on other instances. This article explains how to use an independent test instance to check whether your Mastodon server can send and receive data across the network. You will learn the exact steps to verify federation and what the results mean.
Key Takeaways: Testing Mastodon Federation with a Remote Check Service
- Federation test instance at fedi.tips/check-federation: Sends a test message from an external server to your account to confirm incoming federation works.
- Your Mastodon domain and a public post URL: Required inputs for the test tool to initiate the handshake with your instance.
- Notification of the test message in your Mastodon client: The visible confirmation that your instance accepted a remote post from the test server.
Why Federation Can Fail Without Any Error Message
Mastodon federation relies on ActivityPub, a decentralized protocol. Your instance must be able to receive incoming requests from other servers and deliver outgoing posts to them. Many server admins assume federation works because they can see local posts or follow accounts on popular instances like mastodon.social. But a blocked port, a misconfigured reverse proxy, or a firewall rule can silently break outbound or inbound traffic. The instance itself will not show an error because it cannot detect that the remote server never received the data. An independent test instance bypasses your own server’s view and checks connectivity from the outside.
The fedi.tips check-federation tool is a third-party service that does not belong to your instance. It sends a test post from its own Mastodon server directly to your account. If your instance accepts that post, you know inbound federation works. If the post never arrives, the problem is on your side. This method is more reliable than checking logs because it simulates real user traffic.
Steps to Verify Federation Using the fedi.tips Test Instance
- Open the federation test page
Go to fedi.tips/check-federation in your web browser. This page is maintained by the fedi.tips community and does not require registration. - Enter your Mastodon domain
Type the full domain of your instance, for example mastodon.example.com. Do not include the protocol or a trailing slash. The test tool needs this to route the test message to your server. - Provide a public post URL from your account
Copy the URL of any public post you have made on your instance. The test tool will use this post to verify that your instance can be reached and that the post is visible to external servers. If the post is set to followers-only or unlisted, the test may fail. - Start the test
Click the button labeled Check Federation or similar. The tool will send a test post from its own Mastodon server to your account. This process takes a few seconds. - Check your Mastodon notifications
Open your Mastodon client or the web interface. Look at your notifications tab. You should see a new notification from the test account @feditips@mastodonapp.uk containing the test message. If the notification appears, inbound federation is working. - Verify the test post in your federated timeline
Switch to your federated timeline. The test post from @feditips should appear there as well. This confirms that your instance is not only receiving remote posts but also displaying them in the public feed.
If you do not see the notification within two minutes, refresh the page and try again. Some instances take longer to process incoming ActivityPub messages.
What to Do If the Federation Test Fails
No notification arrives from the test account
This usually means the test server cannot reach your instance. Check your server firewall and reverse proxy configuration. Ensure ports 443 and 80 are open for inbound traffic. Also confirm that your Mastodon sidekiq process is running. Sidekiq handles inbound ActivityPub delivery. If sidekiq is stopped, your instance will not process incoming messages.
The notification arrives but the federated timeline is still empty
This indicates that inbound federation works but your instance may have a filter or a configuration issue that hides remote posts from the public timeline. Check your server’s Site Settings in the admin panel. Make sure the option Limited federation mode is disabled. Also verify that you have not manually muted the test account or the test instance. Go to Preferences > Muted users and Preferences > Muted domains to confirm.
The test succeeds but users on other instances cannot see your posts
Outbound federation may still be broken. Run a second test by asking a friend on a different instance to check if your public posts appear on their federated timeline. If they do not, inspect your outbound sidekiq queues. In the Mastodon admin dashboard, go to Sidekiq > Queues and look for a large backlog in the push queue. A backlog means outgoing deliveries are failing. Common causes are DNS resolution problems or rate limits on the remote server.
| Item | Inbound Federation (Receiving) | Outbound Federation (Sending) |
|---|---|---|
| What is tested | Ability to accept remote posts from another instance | Ability to deliver local posts to remote instances |
| Test method | Use fedi.tips/check-federation to send a test post to your account | Ask a user on another instance to check your public post |
| Common failure signs | No notification from test account, empty federated timeline | Remote users never see your posts, push queue backlog |
| Likely cause | Firewall blocking port 443, sidekiq stopped, limited federation mode enabled | DNS misconfiguration, rate limiting, or server blacklisted |
Now you can confirm whether your Mastodon instance federates correctly with the rest of the fediverse. Use the fedi.tips test tool regularly after server updates or configuration changes. If the test fails, check your firewall, sidekiq queues, and limited federation mode first. For a deeper check, monitor your instance’s sidekiq logs for push failures using the command journalctl -u mastodon-sidekiq -f on the server.