# "Table log_bot_request doesn't exist - in plugin BotTracking": fixing Matomo archiving after an upgrade
> After upgrading to Matomo 5.6–5.8 (or installing through Softaculous), archiving dies with "Table '…_log_bot_request' doesn't exist - in plugin BotTracking". The BotTracking plugin's table never got created. Here's why, and how to put it back so the error doesn't come straight back.
Published: 2026-06-17
Categories: Matomo Self-Hosting
Canonical: https://martez.io/blog/matomo-bottracking-table-doesnt-exist
---
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):
```text
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 archiver fails because BotTracking's `log_bot_request` table never got created during the upgrade or install, so MySQL throws error 1146 every time a site with traffic is archived. Confirm the exact table is missing for your prefix, then run `./console core:update` and let Matomo build it. If Matomo reports nothing pending but the table is still gone, it already thinks BotTracking is installed, so create the table by hand from your own `plugins/BotTracking/Dao/BotRequestsDao.php`. Toggling the plugin off and on won't help: the schema step only runs once, at first install.
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](https://developer.matomo.org/api-reference/tracking-api#tracking-bots) 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, `_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](https://matomo.org/faq/on-premise/matomo-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 `_log_bot_request`, and MySQL returns error 1146 because the table isn't there.
MySQL 5.5 allowed `CURRENT_TIMESTAMP` defaults on `TIMESTAMP`, not on `DATETIME`. Changing `created_time` to `TIMESTAMP` just to make the statement run gives you a hand-edited schema that no longer matches the plugin. Upgrade the database engine instead.
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.
| Path | Best for | Keeps BotTracking telemetry? | Verify |
| --- | --- | --- | --- |
| `core:update` | Interrupted update or installer skipped a migration | Yes, if it creates the table | Exact table exists, then `core:archive` succeeds |
| Manual `CREATE TABLE` | BotTracking is marked installed but the table is missing | Yes, if the schema matches your local plugin | Compare `BotRequestsDao.php`, create table, run `core:archive` |
| Deactivate BotTracking | You do not need AI assistant / bot-request reports | No, not while disabled | `core:archive` succeeds without querying BotTracking |
### 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:
```sql
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):
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:
```sql
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:
```bash
./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](/blog/exclude-bots-from-matomo).
## Verify the fix
After any option that keeps BotTracking enabled, confirm the exact table exists:
```sql
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:
```bash
./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](/blog/matomo-cron-archiving-invalid-response) 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](https://github.com/matomo-org/matomo/issues/24192), reported for 5.8.0, and GitHub still marked it open when checked on June 5, 2026.
If your log says `Undefined constant Piwik\Plugins\BotTracking\Metrics::METRIC_AI_ASSISTANTS_UNIQUE_PAGE_URLS` rather than `Table ..._log_bot_request doesn't exist`, creating `log_bot_request` will not help. Deactivate BotTracking or move to a Matomo release whose official changelog explicitly fixes that issue.
It hits the same [AI chatbot reports](/blog/matomo-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](/blog/fix-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](/?utm_source=martez&utm_medium=blog&utm_campaign=matomo-bottracking-table-doesnt-exist) 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](/signup?utm_source=martez&utm_medium=blog&utm_campaign=matomo-bottracking-table-doesnt-exist) 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.