System Logs and Application Logs in rConfig V8 Core

rConfig V8 Core keeps two separate logging systems: the Application Log for operational business events and the System Logs for framework and runtime diagnostics. After reading this page, you can tell the two apart, choose the right one for a given problem, and know where each is stored and how long it is kept.

The two logging systems

The split exists because operations teams and system administrators are usually chasing different kinds of problem. One records what rConfig did (connected to a device, downloaded a config, ran a task). The other records how the underlying software behaved (exceptions, stack traces, queue failures).

Application Log: business events and operations

The Application Log records structured events tied to rConfig’s core configuration management functions. It answers operational questions such as “Did the device connection succeed?”, “When was this configuration downloaded?”, and “Who changed this setting?”

Typical uses:

• Troubleshooting device connectivity issues
• Tracking configuration change history
• Audit trails for user actions
• Monitoring scheduled task execution

Key characteristics:

• Stored in database tables, so it filters and searches quickly
• Structured data with severity levels, timestamps, and contextual metadata
• Visible in real time through the web interface
• Accessible to operations staff and administrators

System Logs: framework and runtime diagnostics

System Logs hold the technical output from the Laravel framework, the PHP runtime, and the background queue workers. They answer questions such as “Why did the page error?”, “Which code path raised this exception?”, and “What caused the queue job to fail?”

Typical uses:

• Diagnosing application errors and blank pages
• Investigating framework-level exceptions
• Analysing queue worker failures
• Providing detailed error context to rConfig support

Key characteristics:

• Stored as daily rotated files in the filesystem
• Unstructured text with full stack traces and variable dumps
• Viewed through the Log Viewer web interface or the command line
• Restricted to administrators because of the sensitive technical detail they contain

Which log should I use?

Pick the log system from the kind of issue you are investigating.

Symptom	Start with
Device will not connect or authenticate	Application Log
Configuration download failed	Application Log
Scheduled task did not run as expected	Application Log
A user action needs an audit trail	Application Log
Web interface shows a blank page or 500 error	System Logs
Background jobs failing silently	System Logs
Database connection errors	System Logs
PHP memory or timeout errors	System Logs

For complex problems, use both. The Application Log gives you the business context (which device, which task), and the System Logs give you the technical detail (the exact exception and stack trace). Cross-reference the timestamps to line the events up.

Worked examples

A device connection keeps failing. Search the Application Log for the device hostname or IP, filter to Error severity, and review the failure descriptions. If the entries point at a framework exception, switch to the System Logs and search for the exception class name.

A scheduled backup task does not complete. Filter the Application Log for the task’s execution events. If the task started but errored, the cause is usually there. If it was queued but never ran, check the System Logs for queue worker errors and read the stack trace.

A blank page appears on a specific screen. Go straight to the System Logs, open today’s file, scroll to the entries around the time it happened, and read the exception type, message, and the file and line number where it originated.

Where each log lives and how long it is kept

Application Log

rConfig writes structured entries to a database table as operations run, with a severity, timestamp, and description. The entries are immediately visible and searchable in the web interface. Active records stay in the primary tables for fast searching, and aging records can be archived to separate tables for longer retention. On larger deployments, archive regularly so query performance stays fast and database growth stays under control.

System Logs

The Laravel framework and PHP runtime append entries to daily files in /var/www/html/rconfig/storage/logs/. A new file is created each day and you view them through the Log Viewer or from the command line. Old files are removed manually or by a scheduled cleanup task. Set a sensible log level (info or warning in production, not debug) to keep file sizes down, and watch disk space on the log partition so a full disk does not stop rConfig writing logs.

Logs contain sensitive data

Both systems can hold information that needs protecting. The Application Log carries device IP addresses, hostnames, and usernames from authentication events. The System Logs can include credentials or tokens captured in exception contexts, plus stack traces that reveal internal application detail. Restrict System Logs to administrators and sanitise any log output before sharing it outside the organisation.

Sending logs to rConfig support

When you raise a support case, give the support team complete log context. Partial snippets usually leave out the detail needed to diagnose the issue.

From the Application Log, copy the relevant entries showing the problem, including timestamps, severity levels, and full descriptions, and note how often it happens. From the System Logs, download the full daily files covering the incident rather than excerpting the stack traces, and include more than one day if the issue spans a period.

Set the log level before reproducing

When you are actively troubleshooting, raise the log level so more detail is captured, reproduce the problem, then return the level to info or warning. Leaving the system on debug in production fills the log files quickly and buries the entries that matter.

Centralised logging and alerting

Forwarding logs to a SIEM or central log platform, automated alerting on error thresholds, and log shipping with tools like Filebeat or Fluentd are operational add-ons rather than V8 Core features. If you need that level of observability, see the rConfig Pro, Enterprise, and Vector documentation, which covers the editions where those capabilities are documented. V8 Core gives you the local Application Log and System Logs described above.

What’s next

• Manage operational events in the Application Log covers filtering, severity levels, and archiving operational events.
• Read framework logs in the System Logs viewer covers viewing and downloading the daily Laravel log files.
• Automate log archival with scheduled tasks covers setting up the jobs that keep log tables and files trimmed.
• Trace device connection failures walks through diagnosing the connectivity issues that show up in the Application Log.