Site health tasks

Your control panel has a couple of built-in maintenance tasks you can run on any site with a single click — no shell, no Drush to remember. They're the gentle first things to reach for when a site feels a bit off: a change that won't show up, a page served from a stale cache, or just a "let me clear things out" before you go looking for real trouble.

There are two of them, and this page covers both:

  • Flush all caches — clears the site's caches so fresh content shows.
  • Rebuild registry — a deeper rebuild of the site's internal wiring, then a cache flush.

You'll find them the same way for every site: open the site's page in the Aegir control panel and look at its task list (the same list where Verify, Clone and the rest live). Click the task, confirm, and it runs in the background. Neither one changes your content — they just rebuild throwaway data so Drupal builds it again fresh.

These work on your Drupal, whatever its age. Both do the right thing on modern Drupal (8, 9, 10 and 11) as well as older Drupal 6/7 — BOA picks the correct method for your site's version for you. On a modern Composer-managed Drupal 10/11 site the tasks use the site's own bundled Drush behind the scenes, which is what makes them actually take effect there.

Flush all caches

What it does for you. It empties every cache on the site and lets Drupal build them again from scratch. Caches are Drupal's way of remembering expensive work so it doesn't redo it on every page load — but a cache can go stale, and then you see old content, a missing block, or a change that just won't appear no matter how many times you reload.

When to run it. Any time the site is serving something out of date:

  • You edited content, a menu, or a setting and the change isn't showing up.
  • A new block, view or page looks wrong or empty right after you added it.
  • Something small looks broken and you want the quickest possible "have you tried turning it off and on again" before digging deeper.

What a clean result looks like. The task finishes and its status in the task list turns green (successful). Reload your site and the fresh content should be there. That's it — there's no report to read; a successful run is the result.

One caution, straight from the task itself: flushing caches on a busy site makes Drupal rebuild everything at once, which can cause a short load peak while it catches back up. Normally your site's own scheduled cron flushes caches for you on a sensible timetable, so only reach for the on-demand button when you have a reason to — not as a routine habit.

Rebuild registry

What it does for you. This is a heavier version of a cache flush. On a modern Drupal 8+ site it rebuilds the service container — Drupal's internal map of how all its parts are wired together — and then flushes every cache. (On an older Drupal 6/7 site the equivalent is rebuilding the registry tables, which is where the task gets its name.) Either way, you end up with the site's internal wiring freshly rebuilt and all caches cleared.

When to run it. Reach for this when a plain Flush all caches wasn't enough:

  • You enabled, disabled, or updated a module and the site is behaving oddly — "class not found" style errors, a feature that half-works, or a page that errors where it shouldn't.
  • A cache flush helped a little but something still isn't right.
  • You just finished a code change or update and want the most thorough cleanup the control panel offers, short of a full Verify.

On a modern Drupal 8+ site, Rebuild registry and Flush all caches end up doing much the same thing (both rebuild and flush) — so it's fine to start with Flush all caches and only use Rebuild registry if that didn't settle it. Both buttons stay available on modern sites on purpose, so you don't have to think about which era of Drupal you're on.

What a clean result looks like. Same as the cache flush: the task goes green in the task list and your site behaves itself again. The same short-load-peak caution applies — it's a rebuild, so run it when you have a reason, not on a whim.

Checking your site's health

You might remember a Run health check button here, or see it mentioned in older notes. It's no longer offered as a control-panel task, so don't go looking for it — the good news is you don't need it, because everything it used to report is right there in Drupal itself, and you can see all of it from inside the site as an admin:

  • Security updates — Drupal's own Available updates report tells you whether any installed module or theme has a security release you haven't applied yet. This is the most important one to watch.
  • Status report — Drupal's Status report page gives you the same overview: PHP and database versions, when cron last ran, and any warnings Drupal wants to raise. Green and blue lines are fine; red is worth reading.
  • Pending database updates — after you update a module, Drupal will tell you if it has database updates waiting to be applied.

These are all read-only reports — they tell you something needs doing; they never do it for you. Acting on what they show is a separate, deliberate step you take yourself, and it's a good habit to glance at the updates and status reports every so often, and again after you deploy code or update modules.

If any of those reports isn't clean, that's your to-do list. A pending database update is finished by running the update; a waiting module update is applied through your normal update workflow — see Running Drush and Developing your site for how you carry those out. A security update showing up is a nudge to apply it soon.

Where these fit with the rest of troubleshooting

These tasks are the calm, low-risk first moves. If a task itself won't finish — it sits in the queue or comes back red — that's a different problem; see Tasks that won't finish. If your whole site is blank or erroring, work through My site is broken (white screen), which uses a cache rebuild as one of its steps too.

If a rebuild task fails in a way none of this explains, or you keep hitting something you can only fix from the server itself, that's something your host/operator handles — open a support request and share the task log.