Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Logging & Monitoring.

Nextcloud generates logs constantly in the background, and understanding where those logs live and what they’re telling you is a core part of keeping the system healthy. At NZRT, logging ties directly into security auditing, performance monitoring, and catching issues before they become outages. So let’s walk through how all of this fits together.

First, let’s talk about where the logs actually are. There are five main log files you need to know about. The primary one is the Nextcloud application log, sitting at var www nextcloud data nextcloud dot log. This captures all Nextcloud events and is your first stop when something goes wrong. Next is the Apache access log at var log apache2 access dot log, which records every HTTP request hitting the server. Then the Apache error log at var log apache2 error dot log, which captures web server errors specifically. You also have the PHP-FPM log at var log php-fpm dot log for PHP-level errors, and finally the MySQL error log at var log mysql error dot log for anything going wrong at the database layer.

Now, how is logging configured? Inside Nextcloud’s main configuration file, there are a handful of settings that control this. The log type is set to file, so everything writes to disk. The log file path points to that nextcloud dot log location we just mentioned. There’s a log level setting that runs from zero to four — zero being debug, which logs everything including very verbose output, one for informational messages, two for warnings, three for errors, and four for fatal events only. NZRT runs at level two, so warnings and above get captured. The timezone is set to UTC for consistency, and there’s an automatic rotation setting — once the log file hits ten megabytes, it rolls over automatically so you’re not filling up your disk with a single enormous log file.

Next up is health checks. Nextcloud exposes a server info endpoint you can call to get a snapshot of system health. When you query that endpoint with admin credentials, the response tells you the current Nextcloud version, which PHP version and modules are loaded, the database connection status, current disk usage figures, how many users are active, and the state of background jobs. This is your go-to for a quick system pulse check, and it’s also something you can script to run on a schedule.

Speaking of schedules, let’s talk about monitoring thresholds. NZRT watches six key metrics. Disk usage triggers a warning at eighty percent and goes critical at ninety percent. Active concurrent users above one hundred is a signal to think about upgrading your plan. Database connections above eighty percent of the configured maximum need attention. Failed logins exceeding ten per hour are flagged as a potential attack. Background job queues with more than one hundred pending jobs indicate something is backed up. And Redis memory usage above eighty percent of its allocation means your cache is under pressure.

For alerting, there’s a bash script that runs on a cron schedule. What it does is check the current disk usage percentage for the Nextcloud data directory. If that number is above eighty, it sends an email alert to the admin address. It’s a simple but effective early warning for one of the most common failure modes — running out of space.

Now, how do you actually look at the logs day to day? You have two options. Through the web interface, you go into Settings, then Logging, and you’ll see the last entries displayed right there in your browser — no terminal needed. If you prefer the command line, you can stream the log live as events come in using tail, which is great for watching what’s happening in real time during a troubleshooting session. You can also search the log file for error entries and pull just the most recent twenty, which is usually enough to identify a pattern quickly.

To put this all in NZRT context — logging and monitoring aren’t just housekeeping. Failed background jobs can mean the Dolibarr sync isn’t running. A spike in failed logins could be a brute force attempt on the platform. Slow database queries show up in logs before they become user-facing problems. That’s why Dan, our DBA, reviews the logs on a daily basis. Catching something early in the logs is almost always cheaper than dealing with the downstream consequence.

If you want to go deeper, check out the related wiki notes on Administration Overview, Audit Logs, and the occ Command Reference. Those give you more detail on how to act on what the logs are telling you.

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