Database connection refused on port 27017: account loading failure (15 September 2026)

[platypus1223]

Username: At request

Could the production operator check the API-to-MongoDB connection? Account data fails to load, and an independent public API request reproduced the database failure.

Reproduction and evidence

curl --max-time 15 --fail-with-body https://api.monkeytype.com/public/typingStats

At 2026-09-15 03:50:31 UTC, this returned HTTP 500:

{"message":"Could not connect to the database. It may be down.","data":{"errorId":"a852f404-c322-4ad2-b4f8-20631a178e36","uid":""}}

Rechecked at 03:55:10 UTC: same HTTP 500/message, error ID d94d3429-78ae-4903-9233-add772732a05. These are unauthenticated HTTP-client checks, independent of browser cache. Authenticated/incognito browser scenarios were not independently replayed.

The API advertises 2026.08.17_18.17_91bd24bb8. In the matching source, the returned message is selected by:

if (/ECONNREFUSED.*27017/i.test(error.message)) {
  message = "Could not connect to the database. It may be down.";
}

Assuming the advertised source matches deployment, this identifies a refused MongoDB connection. It does not establish why the connection was refused. API / and cached /configuration still return 200; neither establishes database health. The official Instatus summary reported HASISSUES.

Targeted recovery steps

1. Privately compare the running API instance/container's effective DB_URI with the expected production database destination. Inspect the full connection error in process logs around the timestamps above. Test from the API's own network namespace.
2. If the database host uses systemd with a mongod service, run these read-only checks:

sudo systemctl status mongod --no-pager
sudo journalctl -u mongod --since "2026-09-15 03:20:00 UTC" --no-pager
sudo ss -ltnp "sport = :27017"
df -h
df -i
free -m

3. If mongod is stopped, resolve the logged cause first (storage, memory, data mount, etc.), then start the existing service:

sudo systemctl start mongod
sudo systemctl status mongod --no-pager

If it is running, check the intended private listener/address and API-to-database network path. Restore known-good configuration if DB_URI changed incorrectly. For containerized/managed MongoDB, use the existing deployment's recovery procedure instead of the systemd commands; preserve its volume and replica-set configuration.

4. Verify authenticated ping and an application collection read from each affected API instance. Require HTTP 200 with plausible /public/typingStats data, successful account/history loading, and a normal test result that persists after reloading.

These are conditional operator instructions, not a verified production fix. No production changes have been applied. Do not recreate an empty database or delete its volume.

Follow-up

Consider database readiness separately from process liveness, HTTP 503 for database unavailability, and error reporting that does not wait for writes to the unavailable database.