Mastodon ‘Internal Server Error’ When Posting: Diagnostic Steps

When you try to publish a post on Mastodon and see an “Internal Server Error” message, the post usually fails to send. This error means the Mastodon server encountered a problem it could not handle, not a mistake in your content or connection. The cause is almost always on the server side, such as a database timeout, a misconfigured rate limit, or a temporary resource shortage. This article explains the technical reasons behind the error and provides a step-by-step diagnostic process to identify and resolve the issue.

Why Mastodon Returns an Internal Server Error When You Post

An HTTP 500 Internal Server Error is a generic response that indicates the server cannot fulfill the request due to an unexpected condition. When this happens specifically during posting, the problem lies in one of several server-side components:

Database Connection Failure

Mastodon uses PostgreSQL to store all posts, accounts, and relationships. When the database server is overloaded, unreachable, or has reached its connection limit, the Mastodon application cannot write the new post to the database. This triggers an unhandled exception that surfaces as a 500 error.

Sidekiq Worker Queue Backlog

After you click Publish, Mastodon does not immediately process the post. It hands the task to Sidekiq, a background job processor. If Sidekiq workers are stuck, crashed, or overwhelmed by a queue of pending jobs, the post never gets processed. The web process times out and returns a 500 error.

Rate Limiting Misconfiguration

Mastodon enforces rate limits on posting to prevent spam. If the rate limit configuration is too strict or if the rate limiter itself crashes, legitimate posts can be rejected. A misconfigured reverse proxy like Nginx can also return a 502 Bad Gateway, which some clients interpret as an internal error.

Disk Space Exhaustion

Mastodon stores media attachments and temporary files on disk. When the disk is full, the application cannot write new files or update database records. This condition often produces a 500 error during any write operation, including posting.

Diagnostic Steps to Find the Root Cause of a Mastodon Posting Error

Follow these steps in order. Stop when you find the specific error. Do not skip steps unless you are certain the component is healthy.

1. Check the Mastodon production log
   SSH into your server and run: tail -f /home/mastodon/live/log/production.log. Reproduce the error by posting again. Look for lines containing RuntimeError, ActiveRecord::ConnectionTimeoutError, or PG::Error. These lines pinpoint the failing component.
2. Verify Sidekiq is running
   Run systemctl status mastodon-sidekiq or ps aux | grep sidekiq. If Sidekiq is not running, start it with systemctl start mastodon-sidekiq. A stopped Sidekiq means background jobs never execute, causing posting to fail.
3. Check database connectivity
   From the Mastodon directory, run RAILS_ENV=production bin/tootctl db:check. This command tests the database connection. If it fails, check PostgreSQL status with systemctl status postgresql and verify the database credentials in the .env.production file.
4. Inspect disk usage
   Run df -h and look for partitions with 100% usage. If the partition containing /home/mastodon is full, free space by removing old media cache: RAILS_ENV=production bin/tootctl media remove. Then restart the Mastodon web process: systemctl restart mastodon-web.
5. Review Nginx error logs
   If you use Nginx as a reverse proxy, check /var/log/nginx/error.log for 502 or 504 errors. These indicate that the Mastodon web process timed out or crashed. Increase the proxy timeout values in your Nginx configuration: proxy_read_timeout 120s; and proxy_send_timeout 120s;.
6. Restart all Mastodon services
   Run systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming. This clears temporary state and resets stale connections. After restarting, attempt to post again. If the error disappears, the cause was a transient resource issue.
7. Monitor resource usage during posting
   Use htop or top while attempting to post. Look for CPU or memory spikes that cause the web process to be killed by the OOM killer. If the Mastodon web process disappears after a spike, increase system memory or reduce the number of Sidekiq workers in .env.production.

If the Internal Server Error Persists After Basic Diagnostics

Post Fails Only with Media Attachments

If text-only posts succeed but posts with images or videos fail, the issue is likely media processing. Check that ffmpeg and libvips are installed and up to date. Run which ffmpeg and ffmpeg -version. If missing, install them with your package manager. Also verify that the mastodon-media directory has correct permissions: chown -R mastodon:mastodon /home/mastodon/live/public/system.

Error Occurs Only for Specific Account or Post Content

If only one account triggers the error, the account may have corrupted data. Use the Mastodon admin panel to review the account and consider suspending and re-creating it. If the error happens with specific text characters, such as emoji or non-Latin scripts, the database encoding may be incomplete. Ensure the PostgreSQL database uses UTF-8 encoding: SHOW server_encoding;.

Error Appears Intermittently

Intermittent 500 errors often point to resource exhaustion under load. Check the number of concurrent users on your instance. If the instance is overloaded, consider adding more Sidekiq workers or upgrading server hardware. You can also enable request logging in Nginx to correlate error timestamps with traffic spikes.

Mastodon Internal Server Error vs Related HTTP Status Codes

Item	500 Internal Server Error	502 Bad Gateway
Meaning	Mastodon application itself failed to process the request	Reverse proxy (Nginx) could not reach the Mastodon web process
Typical cause	Database timeout, Sidekiq crash, disk full	Mastodon web process stopped or port is unreachable
Where to diagnose	Mastodon production.log and Sidekiq logs	Nginx error.log and systemctl status mastodon-web
Fix approach	Restart services, free disk, fix database connection	Restart web process, check port binding in .env.production

These two errors often appear together. A 502 in the browser can be logged as a 500 in the application log. Always check both the reverse proxy logs and the Mastodon application logs to get the full picture.

Now you can systematically identify why Mastodon returns an Internal Server Error when you post. Start with the production log, then check Sidekiq, the database, and disk space. If the error persists, isolate whether it relates to media, a specific account, or traffic load. For ongoing monitoring, set up log rotation and alerting on the production.log file using a tool like logwatch or a simple cron job that greps for “500” every five minutes.