We have a two domains civicrm setup. On the first domain, everything is normal but on the second one, it takes dozens of seconds to open the dashboad (/civicrm) on the first daily use on every computer.

I can't reproduce the issue if I use a link other that the one that opens the dashboard

Resource URL are absolute.

see below: 5 minutes waiting to display civicrm?reset=1

enter image description here

  • It would be helpful if you could include the version of CiviCRM you are using and the type and version of the CMS you are using (e.g. WordPress, Drupal or Joomla). Apr 8, 2016 at 10:56
  • 1
    sorry about that. It's running on drupal 7.43 / civi 4.7.4
    – Damien
    Apr 8, 2016 at 12:56
  • 1
    Do you have anything set to display on the dashboard? Perhaps a report that filters on a smart group?
    – JoAnne
    Apr 9, 2016 at 7:45
  • I am seeing this same problem. Damien, can you tell us how you solved it, because I tried removing that .htaccess file and CiviCRM just writes a new one. Also, why doesn't CiviCRM just tell us what it's doing during this big long delay? Isn't there a way to turn on debug mode or logging that would indicate what is causing the delay? Thanks Mar 4, 2017 at 10:07

3 Answers 3


There are several things happening on the dashboard, so you'll need to dig further into this yourself to find the real underlying issue. Here are some things which could trigger symptoms like what you're describing.

Database warmup

This is the most common cause of slow dashboards IMO, but it's dependent on your setup; see note re Timeouts below.

Your DB engine keeps frequently used data in memory. When CiviCRM isn't being actively used overnight, that information will be replaced in memory by other data, and will be read from disk. This is slower. (Nightly DB backups frequently push active daily data from memory, as does a changed traffic profile when your staff knock off.)

We have a testing server which hosts multiple WIP databases. It mirrors your description; starting work on Site A will incur a few seconds (or longer) "warm-up" time. This suggests that the server is overloaded (for production use!).

A workaround is to log into the site earlier, before your morning call / coffee brew / whatever. If we know we're working on example.com and example.org today, we can drush uli and visit /civicrm on both sites before we kick off for the day. Moving a delay can make it disappear :)

The ideal solution is to make more memory available to MySQL. Buying memory is probably cheaper than the (admin, staffing) cost of dealing with insufficient memory. :)


If reproducible, a specific five minute time as seen in your screenshot suggests you're hitting a timeout. This is compatible with the next answer, provided that you have a slow dashboard report which takes more than five minutes, so you reliably hit that timeout.

  • You request the CiviCRM dashboard
  • CiviCRM internally requests a report
  • Report spins its wheels for (at least) five minutes
  • CiviCRM stops waiting and serves you the dashboard minus that report.

Observing a predictable delay (=timeout) then a successful response from the server (as opposed to a predictable delay followed by error message from server, or a predictable delay then error message from the browser) indicates that the timeout is happening internally to CiviCRM.

A five minute timeout could be configured at different layers, in your webserver (eg PHP max_execution_time, apache TimeOut) or in CiviCRM codebase (eg cURL's CURLOPT_TIMEOUT). You don't really want to change the timeout, you want to speed up that process so it doesn't hit the timeout!

Dashboard reports

The dashboard is user-customisable, so the reports you choose to show there will affect the time it takes to display. Because the dashboard contents are delivered as a single page to the admin, you can't see which report is fast or slow. Disabling some reports, or observing the internal requests made from CiviCRM (by watching your weblogs) might allow you to see which reports add the load time to the dashboard.

To identify these dashboard report loads in the webserver logs, look for POST requests to /civicrm/ajax/dashboard immediately before your GET request for /civicrm/dashboard?reset=1 is completed. Timing on those requests will indicate if they are the delay factor.

Check MySQL activity too - I use mytop, which is just MySQL's SHOW FULL PROCESSLIST as a command. If you see long-running queries generating reports, you can balance whether to improve the report, remove it from your dashboard, or accept that it's worth the wait.

Reports using memberships / smart groups

If dashboard reports include smart groups or memberships, remember that memberships get updated daily (by cron), and that smart group caching is only for a limited time. Such reports would need to be regenerated the first time they are run after midnight. CiviCRM includes functionality to schedule report generation, so you could keep your contact DB warmed up (or on the boil!) by scheduling a report to display before you start work, or perhaps by embedding the same dashboard reports on a public screen in your office :)

URL / webserver configuration

CiviCRM makes internal requests while delivering the dashboard as well. Slow performance here could be indicative of a misconfiguration, eg:

  • CiviCRM is unable to communicate with the local site
  • CiviCRM is unable to communicate with CiviCRM.org infrastructure
  • DNS on the webserver is slow or incorrectly configured

Issues with these should trigger warnings on the admin screen which you would likely have mentioned, but it's worth checking that too. These warnings can be disabled, which might work to hide the symptoms.

Requests to CiviCRM.org

As above - CiviCRM communicates with CiviCRM.org while loading the dashboard. This functionality can be disabled (can't it?), but if doing so was working but slow or slow to return an error, you'd see a delay in rendering the dashboard also.

  • 1
    Kudos to you, Chris. This answer is gold. Apr 9, 2016 at 20:42
  • Nicely comprehensive! But 5 minutes is such a long time, I'd bet my money on some kind of network issue (i.e. your URL/webserver configuration, or maybe something a little further down). Some kind of proxying setup, e.g. for outgoing http requests from the server would be a prime suspect.
    – Alan Dixon
    Apr 12, 2016 at 19:46

Thank you for all your suggestions. The culprit was a lousy .htaccess in the civicrm/ConfigAndLog folder. It contained a directive that prevented civi to access logs.

  • 1
    That's intentional, CiviCRM is checking that users from the web should not be able to access logfiles over HTTP. Apr 22, 2016 at 19:48
  • @damien I'd file a bug rep to put a temp limit of 20s on just this check. Then sub a patch.
    – JohnFF
    Mar 4, 2017 at 19:38

This could be due to cron not running. Have you set up a cron job? If not, the CMS (content management system) may run maintenance tasks when you first access the site in the morning.

If you are using Drupal you can find more information here: Setting up cron.

You will also need to use cron to run scheduled jobs in CiviCRM - see Managing Scheduled Jobs.

  • 1
    No. The CMS cron runs normally and the CMS itself behaves normally. It's accessing the dashboard that is really slow at first use
    – Damien
    Apr 8, 2016 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.