Matomo stores nearly all of its behavior in a single plain-text file and a small set of database tables, which means most configuration problems on shared hosting trace back to just a few places. Understanding where those settings live, and how the LiteSpeed/CloudLinux PHP stack applies runtime limits, lets you resolve slow archiving, blank dashboards, and connection errors without ever touching a server-level file. Everything below is done through cPanel Jupiter or DirectAdmin Evolution, the File Manager, phpMyAdmin, and Matomo's own admin area.

Where Matomo keeps configuration and how to edit it safely

The authoritative configuration file is config/config.ini.php, located inside your Matomo installation directory (typically /home/USERNAME/public_html/matomo/config/config.ini.php or a subdirectory such as analytics/). This INI file holds database credentials, the trusted host list, the salt used for security tokens, and dozens of optional overrides grouped under section headers like [database], [General], and [Tracker]. Matomo reads default values from config/global.ini.php, but you should never edit that file because an update overwrites it. Any value you want to change permanently belongs in config.ini.php, where it takes precedence.

Before editing, open cPanel → File Manager (or DirectAdmin → File Manager), navigate to the config folder, and use the built-in Code Editor after making a copy of the file. A single misplaced quote or bracket produces a fatal PHP parse error and a white screen, so a backup named config.ini.php.bak is your fastest rollback path. A minimal database block looks like this:

[database]
host = "localhost"
username = "user_matomo"
password = "your_db_password"
dbname = "user_matomo"
tables_prefix = "matomo_"
charset = "utf8mb4"

On Hostiso accounts the database host is almost always localhost, and the username and database name carry your cPanel account prefix. If you recently changed the MySQL user password through cPanel → MySQL Databases, this file will still hold the old password and Matomo will report a connection failure. Update the password line here to match. The [General] section is where you resolve the frequent "Matomo can't be run because it is not being called from the expected hostname" warning by listing every domain you use to reach the panel:

[General]
trusted_hosts[] = "analytics.example.com"
trusted_hosts[] = "www.example.com"
assume_secure_protocol = 1
force_ssl = 1

Adding assume_secure_protocol = 1 is useful when a reverse proxy or LiteSpeed passes HTTPS through in a way that Matomo detects as plain HTTP, which otherwise causes redirect loops or mixed-content tracking failures.

Adjusting PHP limits with .user.ini and PHP Selector

Matomo's report archiving is memory and time intensive, especially on sites with heavy traffic or long date ranges. The two symptoms you will see are HTTP 500 responses during archiving and reports that stop updating. Both usually mean a PHP resource ceiling was hit. Because you cannot edit php.ini or my.cnf at the server level, the correct place to raise these values is either the PHP Selector or a .user.ini file in your Matomo root.

Start in cPanel → Select PHP Version (PHP Selector) or DirectAdmin → Select PHP Version. Switch to the Options tab and set the recommended values directly through the interface, which is the cleanest method on CloudLinux because it respects any hard caps your plan enforces. Reasonable starting points for Matomo are:

memory_limit = 512M
max_execution_time = 300
max_input_vars = 5000
post_max_size = 32M
upload_max_filesize = 32M

If a directive is locked in the selector, place the same values in a .user.ini file at the root of your Matomo install. LiteSpeed and PHP-FPM read this file per directory, and changes apply after the file's cache window (usually a few minutes) or after you touch the file again:

memory_limit = 512M
max_execution_time = 300
max_input_vars = 5000

Confirm the values actually took effect by opening Matomo → Administration → System Check (under Diagnostics). This page reads the live PHP environment and flags any limit below Matomo's recommendation with a red or orange marker, so you never have to guess whether an edit was applied. If max_execution_time keeps resetting during archiving, the better long-term fix is to move archiving off the browser entirely, which the next section covers. Note that on CloudLinux your account also has LVE limits (CPU, physical memory, entry processes) that are separate from PHP directives; if System Check looks correct but archiving still fails intermittently, check cPanel → Resource Usage for LVE faults.

Archiving, cron, and cache configuration

By default Matomo triggers archiving when someone loads a report in the browser, which is exactly what times out on shared hosting. The supported fix is to disable browser-triggered archiving and run the archiver on a schedule. In Matomo → Administration → General settings, set Archive reports when viewed from the browser to No and increase the report processing interval. Then add a cron job through cPanel → Cron Jobs (or DirectAdmin → Cron Jobs) that calls the console command using your account's PHP binary:

/usr/local/bin/php /home/USERNAME/public_html/matomo/console core:archive --url=https://analytics.example.com/ > /home/USERNAME/matomo-archive.log 2>&1

Schedule it hourly. Redirecting output to a log file inside your home directory gives you a plain record to inspect when a run fails, without needing server logs. This single change eliminates the majority of timeout and memory errors because the CLI process runs with its own, more generous limits.

Cache behavior is controlled in config.ini.php under the [Cache] and related sections. Matomo uses a file-based cache in tmp/ by default, and a stale or unwritable cache is a common cause of the dashboard showing old data or throwing template errors after an update. If reports look frozen, delete the contents of tmp/templates_c/ and tmp/cache/ through File Manager, then reload. Make sure the tmp/ directory and its children are writable (permission 755 on folders, 644 on files); Matomo's System Check reports directory permission problems explicitly. To force a full rebuild of the compiled configuration cache after editing the INI file, you can also delete tmp/cache/tracker/, which stores the tracker's cached settings and otherwise serves stale values to your tracking snippet.

Debug settings and reading the local error_log

When a change produces an error you cannot diagnose from the screen, enable Matomo's logging rather than guessing. Add a [log] section to config.ini.php to write diagnostics to a file inside your account:

[log]
log_writers[] = "file"
log_level = "INFO"
logger_file_path = "tmp/logs/matomo.log"

Use INFO for routine tracing and DEBUG only briefly, since debug logging grows quickly and can expose query details you would not want to keep. Read the resulting file through File Manager → View. Separately, PHP-level fatal errors (parse errors in the INI file, exhausted memory, missing extensions) land in the error_log file that LiteSpeed writes into the directory where the failure occurred, usually public_html/matomo/error_log. Opening that file is the quickest way to confirm whether a blank page came from a config typo or a memory limit. Once you have finished troubleshooting, lower log_level back to WARN or remove the [log] block, and delete the old log files so they do not consume your disk quota. Keeping a backup copy of a known-good config.ini.php in your home directory means any future experiment is a one-file restore away.