Skip to Content
TroubleshootingCommon Issues

Common Issues

Quick solutions to the most frequent problems.

DSN shows 0.0.0.0 instead of your domain

If your DSN looks like http://key@0.0.0.0:8080/1, the server is using its TCP bind address instead of your public URL.

Fix: Set PUBLIC_URL in your server environment:

PUBLIC_URL=https://rustrak.yourcompany.com

The DSN will immediately reflect the correct URL on the next API call. See Environment Variables for details.

Events not appearing

Check your DSN

The DSN format is:

http://<sentry_key>@<host>:<port>/<project_id>

Make sure:

  • The host is reachable from your app (set PUBLIC_URL if it shows 0.0.0.0)
  • The port is correct (default: 8080)
  • The project ID exists

Enable SDK debug mode

Sentry.init({ dsn: 'YOUR_DSN', debug: true, // Logs SDK activity to console });

Check network connectivity

# Test from your app's server/machine curl -v http://your-rustrak-server:8080/health

You should see {"status":"ok"}.

Check rate limits

If you’re hitting rate limits, events are dropped. Check server logs:

docker logs rustrak

Look for “rate limit exceeded” messages.

CORS errors

The server already answers CORS for any origin, so a browser SDK on any domain can send events and the preflight passes. The dashboard needs no CORS at all: it calls the API on the origin it was loaded from.

Don’t add CORS headers at your reverse proxy. The browser then sees Access-Control-Allow-Origin twice and rejects the response. If you see CORS errors behind a proxy, check that it passes the OPTIONS request and the X-Sentry-Auth, sentry-trace and baggage headers through to the server unchanged.

Can’t connect to dashboard

The dashboard is served by the server itself, from /, so its address is the server’s address: http://localhost:8080 by default, or your PUBLIC_URL. The sign-in page is /login.

If a page answers with a JSON 404 instead of the dashboard, the startup log says why. It prints one of these lines:

Serving the dashboard from /app/static Dashboard switched off by RUSTRAK_DASHBOARD — serving the API only No dashboard build at ./static — serving the API only
  • Switched off: RUSTRAK_DASHBOARD=off is set. Remove it to serve the dashboard again.
  • No dashboard build: the server was built without one, for example a plain cargo build. The published images always include it.
  • /auth/login: that was the sign-in address before 0.15. It now belongs to the API and answers a JSON 404; open /login instead.

Also check that:

  • You are opening the server’s port (8080 by default)
  • SSL_PROXY=true is set when a proxy terminates HTTPS, or the session cookie is dropped and every page looks signed out
  • No firewall blocks the connection

Server not responding

Check if the server is running:

docker ps | grep rustrak curl http://localhost:8080/health

Database connection errors

Check DATABASE_URL

# Format postgres://username:password@host:port/database # Common mistakes postgres://user:pass@localhost:5432/rustrak # Wrong if using Docker postgres://user:pass@postgres:5432/rustrak # Correct for Docker Compose

Database not ready

The server might start before PostgreSQL is ready. Add a healthcheck:

services: server: depends_on: postgres: condition: service_healthy

Authentication errors

401 Unauthorized (API)

Check your token:

  • Format: 40 hexadecimal characters
  • Header: Authorization: Bearer YOUR_TOKEN
  • Token exists and hasn’t been deleted

Can’t log in to dashboard

  1. Check that the first user was created. CREATE_SUPERUSER=email:password creates an admin only when the database has no users yet; the startup log says Superuser created, or that it skipped creation because users exist. Changing it later does not change an existing account’s password.
  2. Check the email and password. The email is not case-sensitive.
  3. Clear the browser’s cookies for the Rustrak address and try again.

There is no password reset in the dashboard yet. If another admin can sign in, they can remove the account under Settings, Team and invite it again.

High memory usage

Server using too much RAM

Check your rate limits. Processing many events increases memory:

# Reduce limits for constrained environments MAX_EVENTS_PER_MINUTE=100 MAX_EVENTS_PER_HOUR=1000

The dashboard is not the cost

The dashboard is static files the server reads once at startup, so it adds nothing to memory under load. The whole install idles under 100 MB. If you don’t want it anyway, RUSTRAK_DASHBOARD=off serves the API only.

Events delayed

Events go through two phases:

  1. Ingest (immediate): Event received and stored
  2. Digest (background): Event processed and grouped

If events appear delayed, the digest phase might be backed up. Check server logs for errors.

Stack traces still show minified code

If errors show minified file names instead of your real source files, the source maps aren’t reaching Rustrak. Source map upload is a separate channel from error reporting: your DSN sends events to Rustrak, but the build plugin decides where source maps go. The two most common causes:

  1. The upload URL isn’t set → the Sentry build tooling defaults to its hosted service (sentry.io). You must set the plugin’s url option to your Rustrak server. Pointing the DSN at Rustrak is not enough.
  2. No auth token → without authToken, the upload is silently skipped and the build still succeeds.

Verify whether anything was actually uploaded for your project:

curl -H "Authorization: Bearer YOUR_TOKEN" \ http://localhost:8080/api/0/projects/x/your-project/files/source-maps/

An empty data array means no source maps exist for that project yet.

See Source Maps for full setup.

Still stuck?

  • Check server logs: docker logs rustrak
  • Enable debug logging: RUST_LOG=debug
  • Open an issue 
Last updated on