What causes "Umami Dashboard Slow or "Something Went Wrong""?

Millions of rows in website_event on undersized PostgreSQL Queries computed on demand without pre-aggregation Connection pool timeouts under load Container memory limit too low for all-time queries uBlock Origin blocking dashboard API URLs on the Umami instance

How do I fix "Umami Dashboard Slow or "Something Went Wrong""?

1. Rule out the browser: Disable uBlock Origin or other blockers for your Umami domain Hard refresh (Ctrl+Shift+R) and try another browser 2. Give the database more resources: Scale PostgreSQL vertically (CPU, RAM, fast SSD); the maintainer's main advice for scale Raise the Umami container's memory limit above 2 GB if it is being killed 3. Tune connections and indexes: If using pgbouncer, add pgbouncer=true to DATABASE_URL and use transaction pool mode Check that indexes on website_event (website_id, created_at) exist after upgrades Set REDIS_URL to enable caching 4. Move high-volume sites: Use Umami's ClickHouse support for very large datasets Or export your data and move to Umami Cloud

Umami Dashboard Slow or "Something Went Wrong"

Ongoing Self-hosted Updated November 13, 2026Based on 3 user reportsHow we research

Quick answer

On self-hosted PostgreSQL, Umami computes charts from raw events, so long date ranges on big sites can time out or run out of memory. Add database resources and indexes, tune connection pooling, or move high-volume sites to ClickHouse or Umami Cloud. If errors are intermittent, check uBlock Origin on the Umami domain.

Most likely fix: Rule out the browser

How to fix it

Try these in order — the most common fix is first.

1. Rule out the browser
1. Disable uBlock Origin or other blockers for your Umami domain
2. Hard refresh (Ctrl+Shift+R) and try another browser
Did this fix it?
2. Give the database more resources
1. Scale PostgreSQL vertically (CPU, RAM, fast SSD); the maintainer's main advice for scale
2. Raise the Umami container's memory limit above 2 GB if it is being killed
Did this fix it?
3. Tune connections and indexes
1. If using pgbouncer, add pgbouncer=true to DATABASE_URL and use transaction pool mode
2. Check that indexes on website_event (website_id, created_at) exist after upgrades
3. Set REDIS_URL to enable caching
Did this fix it?
4. Move high-volume sites
1. Use Umami's ClickHouse support for very large datasets
2. Or export your data and move to Umami Cloud
Did this fix it?

Symptoms

Last 7 days loads but 30 days, 90 days or all time show 'Something went wrong', the container restarts out of memory, or the dashboard throws 'TypeError: e.datasets[n] is undefined' until a hard refresh.

Why it happens

Millions of rows in website_event on undersized PostgreSQL
Queries computed on demand without pre-aggregation
Connection pool timeouts under load
Container memory limit too low for all-time queries
uBlock Origin blocking dashboard API URLs on the Umami instance

This guide also covers

umami slow
why is umami so slow
umami something went wrong
umami dashboard not loading
umami e.datasets is undefined

Still not working?

If Umami keeps failing, you're not alone. See every Umami problem users report or the alternatives people switch to.

Done fighting Umami? Our small team builds your own Umami alternative, made for how you work. On your domain or hosted by us. Price agreed together.

Get a quote

Fixed it? Share this guide

The same problem in other apps

All not loading, error messages & connection guides →

PostHog Toolbar or Heatmaps Not Loading (PostHog)

Other Umami errors

All 12 Umami errors and fixes →