"Table log_bot_request doesn't exist - in plugin BotTracking": fixing Matomo archiving after an upgrade

If your Matomo archiver started failing right after an upgrade into Matomo 5.7 or 5.8, including a jump from 5.6.x to 5.8.x, and the log keeps pointing at the BotTracking plugin, the report data isn't corrupted and your config isn't wrong. A database table the plugin expects simply isn't there. A scheduled or manual core:archive run ends like this (your database name and prefix will differ):

ERROR [...] Got invalid response from API request: ...method=CoreAdminHome.archiveReports&idSite=1&period=day...
Response was '{"result":"error","message":"SQLSTATE[42S02]: Base table or view not found:
1146 Table 'yourdb.yourprefix_log_bot_request' doesn't exist - in plugin BotTracking."}'
...
X total errors during this script execution, please investigate and try and fix these errors.

The same failure shows up on the dashboard or in the system check as Mysqli prepare error: Table '..._log_bot_request' doesn't exist. Every site that has had at least one visit trips it, because archiving for that site reads the bot-request table and the table was never built.

The table name in the error already tells you what to replace later: yourdb is the database, and yourprefix_ is the Matomo table prefix from config/config.ini.php. The trap a lot of people fall into first is to deactivate BotTracking, run archiving once (it works), then re-enable the plugin and watch the error come straight back on the next visit. That's the tell: it's a missing table, not a broken setting, and toggling the plugin won't create it.

Why the table is missing

BotTracking is a bundled plugin in Matomo versions that include the 5.7+ bot-tracking feature. It powers Matomo's AI assistant / AI chatbot bot-request reports, not a general all-crawlers analytics system; Matomo's current tracking docs say other bot requests may be detected but discarded. Matomo 5.8 expanded this area with dedicated AI chatbot reports. When the plugin installs, its install step is supposed to create one table, <prefix>_log_bot_request, defined in plugins/BotTracking/Dao/BotRequestsDao.php. The archiver reads from that table on every run.

The table goes missing when that install step never finished against your database. We've seen three ways into the same hole.

• An interrupted or incomplete update. The browser's one-click updater times out partway through. Core updates, the dashboard looks fine, and BotTracking's table step never runs.
• An auto-installer that skips Matomo's migrations. A lot of these reports trace straight back to Softaculous: a hand install from the official package on the same host has the table, the Softaculous-provisioned copy doesn't. The plugin shows as active either way. Its schema just never ran.
• A database old enough to reject the CREATE TABLE. The created_time column is DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP. Matomo's published requirements still list MySQL 5.5+ and recommend MySQL 8+ or MariaDB, but this BotTracking DDL needs a database that supports DATETIME DEFAULT CURRENT_TIMESTAMP, such as MySQL 5.6.5+ or a compatible MariaDB. On an older engine the create can fail during install and the plugin can end up marked as installed with nothing behind it.

All three land you in the same state. BotTracking is enabled, the archiver queries <prefix>_log_bot_request, and MySQL returns error 1146 because the table isn't there.

This is also why the disable-then-re-enable trick fails. Matomo records BotTracking as already installed in its internal option table, and it only runs the plugin's schema-creation step once, at first install. Flipping the plugin off and on doesn't re-run that step, so the table never reappears. The one run that succeeds is the one where the plugin is off and nothing queries the table.

How to fix it

Do these in order: read your prefix and check whether the exact table exists; run core:update; if Matomo has no pending update and the table is still absent, create it from your installed Matomo source; only disable BotTracking if you accept losing future BotTracking telemetry.

1. Read your prefix and check the exact table

Open config/config.ini.php and read tables_prefix under [database]. If the prefix is matomo_, the intended table is matomo_log_bot_request; if the prefix is dbuser_, it is dbuser_log_bot_request.

Then check that exact table name, not a loose wildcard:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'matomo_log_bot_request';

Replace matomo_ with your real prefix before running the query. If multiple Matomo installs share one database, this exact match matters; %log_bot_request% can match the wrong prefix or stale tables.

2. Re-run Matomo's database update from the command line

From your Matomo root directory (where the console file lives):

./console core:update

On Windows/IIS use php console core:update. This applies any pending updates, including installing bundled plugins that aren't installed yet. If BotTracking genuinely never installed (the interrupted-updater or Softaculous case), this is the supported way to let Matomo build the table itself, and you want a clean "Database upgrade complete" at the end.

The catch: if Matomo already recorded BotTracking as installed but the table creation had silently failed (the old-MySQL case), core:update finds nothing pending and reports it has nothing to do. It won't recreate the table. When that happens, use the manual table step.

3. Create the missing table by hand

This is the fix that holds when Matomo has BotTracking marked as installed but the table is still absent. Back up the database first. Open plugins/BotTracking/Dao/BotRequestsDao.php in your own install, find the column definition, and reproduce it as a CREATE TABLE that matches your installed plugin version.

Use the SQL below only after comparing it with your own plugins/BotTracking/Dao/BotRequestsDao.php. If your file differs, your installed file wins. In Matomo 5.8.0 builds the structure is:

CREATE TABLE `matomo_log_bot_request` (
  `idrequest` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  `idsite` INT UNSIGNED NOT NULL,
  `server_time` DATETIME NOT NULL,
  `created_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `idaction_url` INT UNSIGNED NULL,
  `bot_name` VARCHAR(100) NOT NULL,
  `bot_type` VARCHAR(50) NOT NULL,
  `http_status_code` SMALLINT UNSIGNED NULL,
  `response_size_bytes` INT UNSIGNED NULL,
  `response_time_ms` INT UNSIGNED NULL,
  `source` VARCHAR(50) NULL,
  PRIMARY KEY (`idrequest`),
  INDEX `index_idsite_server_time` (`idsite`, `server_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Three things before you run it:

1. Replace matomo_ with your real table prefix; it's under tables_prefix in the [database] section of config/config.ini.php, and it might be mt8k_, dbuser_, or anything else.
2. Match the engine, character set, and collation to the rest of your Matomo tables: run SHOW CREATE TABLE matomo_log_visit; on an existing one and copy its ENGINE, DEFAULT CHARSET, and COLLATE if present.
3. Check the database version with SELECT VERSION(); before running DDL. If it is too old for DATETIME DEFAULT CURRENT_TIMESTAMP, upgrade the engine instead of changing the column type.

4. Turn BotTracking off if you don't need it

If AI assistant / bot-request reports aren't part of how you read your analytics, deactivating the plugin removes the failing query for good:

./console plugin:deactivate BotTracking

Leave it off and the archiver stops touching the table entirely. This is a real long-term option, not only a workaround: core visit tracking, archiving, conversions, and every standard report run fine without BotTracking. You lose no standard visit or conversion data. You will not collect BotTracking / AI chatbot request telemetry while the plugin is disabled, and rows that were never recorded cannot be recovered later. Turn it back on once the table exists if you decide you want those reports.

If your actual goal is keeping bots out of your human visit numbers, that's a separate job worth getting right; see excluding bots from your Matomo reports.

Verify the fix

After any option that keeps BotTracking enabled, confirm the exact table exists:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'matomo_log_bot_request';

Again, replace matomo_ with your real prefix. You should get the one intended table name back for that prefix. Then confirm archiving completes cleanly:

./console core:archive --force-all-websites

A run with no "SUMMARY OF ERRORS" block means you're clear. Then reload a report in the dashboard and check that data has moved past the upgrade date. If the archiver still throws "got invalid response" errors but stops mentioning a missing table, the cause has shifted; our walkthrough of the cron archiving "invalid response" error covers the other usual triggers.

A different 5.8.0 bug that looks similar

Matomo 5.8.0 also shipped a separate BotTracking bug that breaks archiving: an undefined-constant error, METRIC_AI_ASSISTANTS_UNIQUE_PAGE_URLS, raised inside the plugin's AI-assistant reports. It is tracked upstream as matomo-org/matomo issue #24192, reported for 5.8.0, and GitHub still marked it open when checked on June 5, 2026.

It hits the same AI chatbot reports BotTracking was expanded to provide, but it is not the missing-table problem this article fixes.

Prevent it next time

• Finish every upgrade with ./console core:update from the CLI instead of trusting the browser updater alone, and watch for a clean "Database upgrade complete."
• Back up your database before upgrading, so you can diff the schema if something comes out missing afterward.
• If you provision Matomo through a hosting auto-installer like Softaculous, check that the plugin tables exist once it's done, or install from the official Matomo package and skip the whole class of problem.

For the wider pattern of archiving falling over on a schema mismatch after an upgrade, our guide to fixing Matomo database errors covers the rest of the family.

What we'd actually do

If your archiver has been down since an upgrade and you need reports moving again today, build the table by hand from BotRequestsDao.php after checking the exact prefix and local schema. It's the one fix confirmed to stick when Matomo already thinks BotTracking is installed, and it leaves Matomo owning the schema from then on. Reach for core:update first only when this is a fresh or visibly interrupted install where the plugin never installed at all; that's the case it clears cleanly.

If you're on MySQL 5.5 or an ancient MariaDB, don't paper over the CURRENT_TIMESTAMP rejection. Upgrade the database engine. It's the root cause, and it'll keep biting you on future migrations until you do. And if you never look at AI assistant / bot-request traffic anyway, deactivate the plugin and move on.

Martez connects Matomo with Meta Ads and Google Ads so ROAS, CLV, and attribution sit next to your web analytics instead of in a separate spreadsheet. It's in private beta. Join the waitlist if that's relevant to you.

A missing table reads like a disaster in the archiver log. In the common missing-table case, the fix is a single correctly matched plugin table. The important part is matching your installed Matomo version and table prefix before you run it.