Just cannot get archiving to work

The auto archiving simply doesn’t work here. I tried the CRON and also the web cron version via WGET or CURL. Always get following errors:

Got invalid response from API request: ?module=API&method=CoreAdminHome.archiveReports&idSite=2&period=day&date=2022-09-05&format=json&trigger=archivephp. The response was empty. This usually means a server error.
Error unserializing the following response from ?module=API&method=CoreAdminHome.archiveReports&idSite=2&period=day&date=2022-08-29&format=json&trigger=archivephp: ‘’

We are on shared hosting with memory limit set to 4GB!
System check shows everything is ok except Archiving obviously.
No errors in server log.
Matomo 4.11.0

Any ideas anyone?

Is there any error in the Matomo error log file?

As you mentioned you are using shared hosting so you will be using web cron instead of cron tasks. So, you will be using following request to implement the auto archiving.


I hope you will be changing https://matomo.your-server.example/path/to/matomo and XYZ according to your requirement. Is that Correct?

What is the output if you run the above URL with changed parameters in the browser?

the output is exactly the same as when running a cron. tons of unserialize errors.
the only way archiving works is by using the browser method. but that’s not really great

yes, now that I enabled error logging, I can see lots of errors:

ERROR Piwik\FrontController 2022-09-06 09:13:06 UTC 2836360 Uncaught exception: /home/user/domains/mydomain.com/public_html/matomo/vendor/symfony/console/Symfony/Component/Console/Input/Input.php(77): Not enough arguments. [Query: , CLI mode: 1]


Got invalid response from API request: ?module=API&method=CoreAdminHome.archiveReports&idSite=2&period=day&date=2022-09-06&format=json&trigger=archivephp. The response was empty. This usually means a server error. A solution to this error is generally to increase the value of ‘memory_limit’ in your php.ini file. For more information and the error message please check in your PHP CLI error log file. As this core:archive command triggers PHP processes over the CLI, you can find where PHP CLI logs are stored by running this command: php -i | grep error_log


Error unserializing the following response from ?module=API&method=CoreAdminHome.archiveReports&idSite=2&period=day&date=2022-09-06&format=json&trigger=archivephp: ‘’

we’re on PHP 7.3 and all required php modules are installed and working.

Which version of Matomo do you run?

Have a look at:

as posted in my initial thread. optimized tables, still the same.
are there any devs in here that are able to help with the self hosted version?

@innocraft , any idea?

Hi @trackymctrackface, you have 4GB available for your plan but its possible you aren’t actually using 4GB for your archiving cron.

Can you try setting a specific memory limit for the archiver using this option:

--php-cli-options="-d memory_limit=3G"

This will set the memory limit for the archiving process to 3GB. If your web server doesn’t support managing processes via cli - this would mean it will still use the web request limit.

Can you also provide us with the output of:

./console diagnostics:run --all | grep -i "processes via cli"

Hope this helps,

where do I define this? I tried adding it to my cron, but only get the response:

Command “–php-cli-options=-d memory_limit=3G” is not defined

ok, changed the cron to:

/usr/local/bin/php -f /home/mydomain/public_html/matomo/console -–php-cli-options="-d memory_limit=3G" core:archive --url=https://domain.com/matomo/ > /home/domain/domains/domain.com/public_html/matomo/matomo-archive.log

and the output now is:
Error in argument 3, char 2: option not found

output is
Set up Cron - Managing processes via CLI: OK Ok

Hi @trackymctrackface

Thanks for getting back to us.

That error message indicates a potential issue with the PHP CLI binary used (Since it doesn’t recognize the option used for the memory_limit)

Could you check what the output of the following is:
/usr/local/bin/php -v

It should return the correct CLI version such as:
PHP 8.0.21 (cli) (built: Jul 8 2022 03:42:26) ( NTS )

If it instead returns a different output other than cli, such as:
PHP 8.0.21 (cgi-fcgi) (built: Jul 8 2022 03:42:04)

Then you may need to use a different PHP binary for the crontab command. There should be several version available in the /bin location on the server. (For example /usr/bin/php8.0 or /usr/bin/php7.4

Could you give this a try and let us know if it works?

P.S. For the actual command option you should ensure that you use a double dash --, the forum software used here automatically converts a double dash into – when not used in a code block which might also be an issue here. So the full crontab command would be:
/usr/local/bin/php -f /home/mydomain/public_html/matomo/console --php-cli-options="-d memory_limit=3G" core:archive --url=https://domain.com/matomo/ > /home/domain/domains/domain.com/public_html/matomo/matomo-archive.log

output is:
PHP 7.4.30 (cli) (built: Jun 7 2022 20:23:47) ( NTS )

so that looks ok.
I did fix the double dash for the cron, same results, just can’t get this to work :frowning:

also as mentioned in my first post, it’s the same result when I run it as web cron version via WGET, so this shouldn’t even use the cli