Your Mautic Dashboard Shouldnt Make You Wait

Seventy-seven seconds. That's how long the dashboard took.

Let me paint the picture. It's 6:40 in the morning. Your marketing team opens their laptops, coffee in hand, ready to check how yesterday's campaign did. They log into Mautic.

And they wait. And wait. Then the proxy gives up and they get a 504.

That's exactly what one of our clients was living with on a busy Mautic 7.1 install. The first login of the day took 77 seconds to load the dashboard. Sometimes it never loaded at all.

Here's the thing: nobody blames the database when this happens. They blame Mautic. They blame the tool you recommended. And honestly? A marketing platform that makes people stare at a spinner every morning is a platform people stop opening.

So we fixed it. And we did it without touching a single line of Mautic core.

What's actually going on under the hood

When you log into Mautic, it sends you straight to the dashboard. And the dashboard does something you might not expect: it calculates every single widget, right then, inside your login request.

Most widgets are cheap. One isn't. The "unique visits over time" widget counts distinct contacts per day across the page_hits table. On this install that table held about 9.7 million rows and 16GB of data. The default 30-day range covered basically all of it.

So every morning, the first person to log in paid for a full table scan. That one widget alone took about 72 of the 77 seconds.

Mautic does cache widget results. But the default cache lifetime is just 10 minutes. Overnight, everything expires. The first person in each morning gets the cold, slow version. Everyone after them gets the fast one, until it expires again.

In other words: somebody always has to take the hit. The question is whether that somebody is a human or a cron job.

Enter the Dashboard Warmup plugin

The idea is dead simple: let a robot log in first.

The Dashboard Warmup plugin adds one console command, mautic:dashboard:warm-cache. You schedule it before your team starts work. It walks through every published user, builds their dashboard exactly the way Mautic would, and stores the results in the cache. When the real human shows up, the dashboard is already waiting for them.

Sounds easy, right? Here's where it got interesting. A naive version of this "works" and does absolutely nothing. Three details make the difference:

1. It logs in as each user. Dashboard widgets belong to the person who created them. Warming them as some generic admin fills the cache with the wrong dashboard.
2. It uses each user's language and timezone. This one bit us. The user's locale is part of the cache key. Our first version warmed everything in English, and our Hungarian users' requests never even looked at those entries. Same data, different key, zero benefit.
3. It fakes a browser session. Mautic reads the dashboard date range from your session. The command line doesn't have one, so the plugin gives it an empty session and Mautic falls back to the default range.

It also prints how long each widget took and flags any widget that errors out. Mautic normally swallows those errors quietly, so this is a nice bonus for spotting the slow or broken widget on your own install.

How to set it up

Five minutes of work. Here's the whole thing:

You can find the plugin here.

1. Drop the plugin in. Copy MauticDashboardWarmupBundle into your plugins/ folder and clear the Mautic cache.
2. Raise the cache lifetime. This is the step people skip, and without it warming is pointless. Set cached_data_timeout in config/local.php to something that outlives the night. We went from 10 minutes to 720 minutes (12 hours).
3. Run it once by hand to see what you're dealing with:
   • sudo -u www-data php bin/console mautic:dashboard:warm-cache
   • Want just one user? Add --user=admin (repeat it for more).
   • Want a clean slate? Add --force to drop the existing widget cache first.
4. Schedule it. We run it at 06:00 and 12:00, ahead of the team's ~06:40 login and the lunchtime check-in:
   • 0 6,12 * * * php /var/www/html/mautic/bin/console mautic:dashboard:warm-cache

One big gotcha: run it as the web server user (usually www-data), never as root. If root writes the cache files, the web server can't read them, and you've warmed a cache nobody can use.

One small caveat: it warms the default date range. If someone picks a custom range in the UI, that's their own cache entry, and they'll pay for it the first time.

The results (and what we learned)

The first-login dashboard went from 77.04 seconds to 0.02 seconds. Not a typo. From "go make another coffee" to instant.

To be fair, the plugin wasn't the only fix. We also gave the database room to breathe and helped the slow query along:

The index made the slow query less slow. The warmup made it invisible. That's the real lesson: some queries on a big Mautic install are just expensive. You can't always make them fast, but you can make sure a human never waits for them.

The other lesson: build it as a plugin, not a core hack. It would have been tempting to tweak the dashboard controller directly. But edits to Mautic core get wiped on the next upgrade, and then you're debugging the same problem twice. A plugin lives in plugins/, survives upgrades, and can be turned off in seconds.

One heads-up if you do this yourself: Mautic's .gitignore excludes plugins/*. Your custom plugin won't be in the main repo, so give it its own version control and back it up.

The bottom line

Your dashboard is the first thing your team sees every day. If it's slow, Mautic feels slow, no matter how well everything else runs.

You don't need a bigger server or a rewrite. You need the expensive work to happen at 6am, while everyone is still asleep.

Is your Mautic dashboard dragging in the morning? Run the warmup command once with a stopwatch running and see which widget is eating your time. And if you'd rather have someone dig into it with you, reach out. This is exactly the kind of thing we love fixing.