Welcome to the NZRT Wiki Podcast. Today we’re looking at Logs & Cache.

This episode covers server log locations, how log rotation works, and how to manage the LiteSpeed cache in the NZRT hosting environment. Whether you’re troubleshooting an issue or just keeping things tidy, knowing where your logs live and how to clear your cache is essential.

Let’s start with log paths. There are four main types of logs you’ll deal with. First, access logs and error logs — both of these sit in the logs folder under DavWWWRoot. The access logs track per-subdomain HTTP requests, while the error logs capture Apache and LiteSpeed errors. If you’re seeing something broken on one of your subdomains, this is your first stop. Third, cPanel access logs are found directly inside cPanel under the Logs section — these cover WHM and cPanel login activity. And fourth, mail logs are accessible in cPanel under Email Deliverability — that’s where you’ll find the Exim mail log if you’re chasing a delivery issue.

How do you actually get to these log files? The full path goes through WebDAV — it’s a network drive connection to the hosting server over a secure SSL connection on port 2078, pointing to that DavWWWRoot logs folder. If you’ve already got the WebDAV drive mapped in Windows, navigating to the logs folder from there is the easiest approach.

Next up, log rotation. The good news here is that cPanel handles this automatically, so you don’t need to set anything up yourself. Rotation typically happens monthly. When logs rotate, they get compressed and held briefly before being deleted — so if you need an older log, don’t wait too long. If you want to download raw access logs, you can find them in cPanel under Metrics, then Raw Access.

Now let’s talk about LiteSpeed Cache. LiteSpeed is the web server NZRT runs, and it has its own caching layer that sits in front of WordPress. The cache files live in a folder called lscache under DavWWWRoot, and the behaviour of that cache is controlled by the LiteSpeed Cache WordPress plugin, configured separately per subdomain.

There are three ways to purge the cache when you need to. The first and most common is through the WordPress admin panel. You go into the LiteSpeed Cache menu, click Purge, then Purge All. Simple. The second way is through cPanel — look for the LiteSpeed Web Cache Manager and use Flush All from there. The third option is a direct delete — you go into the lscache folder via WebDAV and delete the contents manually. That one works, but use it carefully, since you’re touching the live file system directly.

It’s also worth understanding the cache rules in place for WordPress sites. There are four key behaviours to know. Static assets like images, scripts, and stylesheets are cached for one year — that’s a long time-to-live, intentionally set for performance since those files rarely change. Pages are cached for one hour by default, though that’s configurable if you need more or less freshness. WooCommerce pages and other dynamic pages are excluded from the cache entirely, because you don’t want users seeing stale cart or checkout data. And finally, if a user is logged in, the cache is bypassed completely for them — so admins and members always see live content.

Finally, there are some monitoring recommendations worth flagging. First, set up uptime monitoring for all four NZRT subdomains — tools like UptimeRobot can notify you immediately if something goes down. Second, make a habit of reviewing error logs weekly, specifically looking for PHP errors or any 500-level server errors that could indicate something quietly broken in the background. Third, consider archiving your access logs monthly — either to the wordpress-backups folder via WebDAV or to Nextcloud for longer-term storage. And fourth, if you want to make this a proper routine, add a log review task as a recurring item in your Dolibarr Projects so it doesn’t slip through the cracks.

Two quick related topics to keep in mind as well. The cPanel Overview wiki page covers the full Metrics and Logs section in more detail. And if you’re looking at security-related logs — specifically Imunify360 threat activity — that’s covered in the Security Overview wiki page.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.