System Information¶

Versions, audit log, logs and license notices in calServer V2.

Overview¶

Under Administration > Diagnostics (/v2/admin/info) there are five tabs. Each tab only appears when the corresponding operation is granted:

Tab	Content	Operation
Informationen	Versions of calServer, API, frontend and backend	`user_management_view`
Audit-Log	Audit trail of the system, see Audit Trail	`user_management_view`
System Log	Log from the database	`information_view`
Anwendungslog	Laravel log files	`information_view`
Lizenzen	License notices of the shipped third-party components	`information_view`

Version Information¶

The Informationen tab shows:

Item	Content
Application	calServer version
API version	Version of the REST API v2
Frontend	Nuxt and PrimeVue version
Backend	Laravel and PHP version

GET /api/v2/app/version returns the same information without authentication.

System Data via the API¶

The interface does not show further system data. It is available through the API and requires the information_view operation:

Endpoint	Returns
`GET /api/v2/admin/information/system`	PHP and Laravel version, web server, operating system, limits for upload, POST and memory
`GET /api/v2/admin/information/database-size`	Name and size of the database
`GET /api/v2/admin/information/dms-size`	Path and size of the DMS storage
`GET /api/v2/admin/information/app-size`	Path and size of the application files

For an overview of the runtime environment on the server:

docker exec calserver-api-v2 php artisan about

Health Check¶

The health check endpoint returns a machine-readable status check without authentication:

GET /api/v2/health

{
    "status": "healthy",
    "services": {
        "database": "up",
        "database_error": null,
        "php_version": "8.3.x",
        "laravel_version": "13.x"
    },
    "meta": {
        "api_version": "2.0.0",
        "timestamp": "2026-09-28T12:00:00+02:00"
    }
}

If the database cannot be reached, the endpoint responds with HTTP 503, "status": "degraded" and "database": "down"; database_error then states the reason.

Logs¶

The Administration > Diagnostics page keeps two logs that show different things:

Tab	Source	Contains
System Log	`log` table in the database	Messages from V1 (Yii) and V2 (API) together; the "source" column separates them
Anwendungslog	Laravel log file (`storage/logs/*.log`)	Additionally class, file, line and stack trace of an exception, as well as the API access lines

Clearing Logs¶

Both logs can be cleared in the interface. This requires the log_delete operation; viewing (information_view) is not enough.

System Log: Single entries via the trash icon, or "clear" for everything that matches the filters currently set (level, source, category, time period). Without filters it affects the whole log.
Anwendungslog: "Clear" affects the file currently selected; the option "clear all files" includes the rotated ones.

The files are truncated to 0 bytes, not deleted. A running write keeps the file open; deleting it would let that process continue writing into a file without a name, and the log would appear empty until the process restarts. Truncating also keeps owner and permissions of the file.

The application log contains personal data

Every API access line carries the client IP of the caller. There is no automatic retention period for it: whoever needs one clears the log regularly or switches the access lines off entirely (API_REQUEST_LOG=false, see config/logging.php).

Permissions¶

Operation	Allows
`information_view`	View system information, System Log, application log and license notices
`log_delete`	Clear the System Log or delete single entries, clear application log files

log_delete is deliberately separate: whoever looks for a problem needs the log; whoever deletes it removes the trace of an event. Existing roles do not receive the operation automatically on update; it is granted in role management.

Regular checks

Check the logs regularly to detect problems early.