How to Audit Relay Traffic Volume on a Mastodon Instance

Mastodon instance administrators often need to understand how much network traffic relays generate. Relays distribute public posts across multiple servers, which can consume significant bandwidth and storage. Without regular audits, a single misconfigured relay can degrade instance performance for all users. This article explains how to audit relay traffic volume using built-in Mastodon tools and PostgreSQL queries.

Understanding Relay Traffic in Mastodon

Relays in Mastodon function as activity hubs that forward public posts from one server to many others. When you connect a relay, your instance sends all public posts to the relay, and the relay sends back posts from other connected instances. This bidirectional flow can result in high traffic volumes, especially on popular relays with hundreds of member servers.

How Relays Affect Instance Performance

Each relay connection adds two traffic streams: outbound (your posts pushed to the relay) and inbound (relayed posts from other servers). The inbound stream is typically larger because it aggregates content from all other relay members. High inbound traffic can fill the database with federated statuses, increase Sidekiq job queues for processing, and consume disk space for media attachments that your local users may never view.

What Data the Relays Table Contains

Mastodon stores relay information in the relays database table. The key columns for traffic auditing are inbox_url, state, follow_activity_id, and the timestamps created_at and updated_at. However, the table does not store cumulative byte counts by default. To measure traffic volume, you must examine Sidekiq job statistics and server logs, or use external monitoring tools like Prometheus.

Steps to Audit Relay Traffic Volume

The following steps guide you through auditing relay traffic using the Mastodon admin interface, PostgreSQL queries, and Sidekiq monitoring. Perform these steps on your Mastodon server via SSH or the web interface.

1. Access the Relays Admin Page
   Log in to your Mastodon instance as an administrator. Go to the administration panel by clicking the gear icon in the top right corner. Select Administration > Relays. This page displays every relay your instance is subscribed to, along with its current state (enabled, disabled, or pending approval). Note the total number of relays and their statuses.
2. Check Relay Status Indicators
   On the Relays page, each relay shows a status badge. A green badge means the relay is active and exchanging traffic. A red badge indicates a connection failure. If a relay is disabled, it generates no traffic. Click the relay name to view its inbox URL. Copy the inbox URL for the next step.
3. Query the Database for Relay Activity
   Open a terminal session on your Mastodon server. Connect to the PostgreSQL database using the command psql -d mastodon_production -U mastodon. Run the following query to list all relays and their last activity times:
   SELECT id, inbox_url, state, created_at, updated_at FROM relays ORDER BY updated_at DESC;
   This query shows when each relay last sent or received data. A relay with a very old updated_at timestamp may be idle or disconnected.
4. Measure Inbound Traffic with Sidekiq
   Relay traffic is processed by Sidekiq workers. Open the Sidekiq dashboard by navigating to https://yourinstance.com/sidekiq (requires admin login). Go to the Queues tab. Look for queues named push, pull, and default. The push queue handles outbound relay deliveries; the pull queue handles inbound relay processing. High queue depths in either queue indicate heavy relay traffic. Note the queue depth and latency values.
5. Estimate Byte Volume from Server Logs
   Mastodon logs HTTP requests to the relay inbox. On your server, run the following command to count bytes received from a specific relay in the last 24 hours:
   sudo journalctl --unit=mastodon-web -S "24 hours ago" | grep "relay_inbox_url" | awk '{sum += $10} END {print sum}'
   Replace relay_inbox_url with the actual inbox URL from step 2. This command sums the Content-Length header of incoming relay requests. The result is in bytes. Repeat for each relay to compare volumes.
6. Compare Traffic Across Relays
   Create a simple spreadsheet with columns for relay name, inbox URL, state, last activity, and estimated daily bytes. Populate the data from steps 3, 4, and 5. This comparison helps identify which relay consumes the most bandwidth. If a relay shows extremely high inbound traffic, consider disabling it or replacing it with a more restrictive relay.

Common Issues When Auditing Relay Traffic

Relay Traffic Does Not Show in Logs

If the journalctl command returns no results, the relay may be idle or the web server logs are rotated before you query them. Check the updated_at timestamp in the database first. If the relay was updated recently but logs show nothing, your logging configuration may exclude request bodies. Ensure the Mastodon web service logs at the info level or higher.

Sidekiq Queue Shows Persistent High Latency

A queue depth above 1000 with latency over 30 seconds indicates that relay traffic is overwhelming your Sidekiq workers. To mitigate this, reduce the number of connected relays or increase the number of Sidekiq processes. You can also enable the sidekiq-throttled gem to rate-limit relay processing. Disable any relay that is not essential for your community.

Database Query Returns No Relays

If the relays table is empty, your instance has never subscribed to any relay. This is normal for small instances. To start using relays, go to Administration > Relays and click Add new relay. Enter the relay inbox URL from a trusted relay list. After adding, repeat the audit steps to monitor traffic.

Mastodon Relay Traffic Sources: Inbound vs Outbound

Item	Inbound Traffic	Outbound Traffic
Direction	Relay to your instance	Your instance to relay
Content	Public posts from all other relay members	Public posts from your local users
Volume typical	10x to 100x larger than outbound	Proportional to your user activity
Impact on DB	High: stores federated statuses and media	Low: only sends already-stored statuses
Monitoring tool	Sidekiq pull queue depth and log bytes	Sidekiq push queue depth and log bytes

After completing this audit, you can identify bandwidth-heavy relays and decide whether to keep, disable, or replace them. Regularly schedule this audit every month to catch traffic spikes early. For advanced monitoring, consider integrating Prometheus with the Mastodon metrics endpoint at /metrics to automate traffic collection and alerting.