Logging and Monitoring | Keyfactor Docs

The application logging is by default displaying informative messages for monitoring and statistic purposes.

SignServer provides three mechanisms for observability in a Kubernetes deployment: application logs, a health check endpoint, and Kubernetes liveness and readiness probes. This page explains how each works and how to configure them.

For an overview of all available deployment parameters, see SignServer Helm Deployment Parameters.

Application Logging

Log Levels

SignServer has two separate log level controls: one for the SignServer application itself, and one for the underlying WildFly application server.

Parameter	Default	What it controls
`LOG_LEVEL_APP`	`DEBUG`	SignServer application log level. Controls signing operation logs, worker events, audit events, and application errors.
`LOG_LEVEL_APP_WS_TRANSACTIONS`	-	Log level specifically for Web Service transaction logging. Set independently if you need verbose WS logging without raising the overall app log level.
`LOG_LEVEL_SERVER`	`INFO`	WildFly application server log level for the main system.
`LOG_LEVEL_SERVER_SUBSYSTEMS`	`WARN`	WildFly log level for subsystems (JBoss modules, connectors, etc.).

Valid values for all levels: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF.

Default log level: LOG_LEVEL_APP defaults to DEBUG, which is verbose. For production deployments consider setting it to INFO to reduce log volume and make significant events easier to spot. Set it to DEBUG temporarily when troubleshooting.

Configure in your values.yaml:

YAML

signserver:
  env:
    LOG_LEVEL_APP: INFO
    LOG_LEVEL_SERVER: INFO
    LOG_LEVEL_SERVER_SUBSYSTEMS: WARN

Saving Logs to Files

By default, SignServer logs are written to stdout and captured by the Kubernetes logging infrastructure. To also save logs to files, configure the storage location and size limit:

Parameter	Default	Description
`LOG_STORAGE_LOCATION`	-	Path inside the container where log files are written. Must be a writable directory. Leave empty to log to stdout only.
`LOG_STORAGE_MAX_SIZE_MB`	`256`	Maximum total size of log files in MB before rotation. Minimum: `2`.

YAML

signserver:
  env:
    LOG_STORAGE_LOCATION: /opt/signserver/logs
    LOG_STORAGE_MAX_SIZE_MB: 512
  volumeMounts:
    - name: log-storage
      mountPath: /opt/signserver/logs
  volumes:
    - name: log-storage
      emptyDir: {}

To persist logs across pod restarts, replace emptyDir with a PersistentVolumeClaim.

Audit Logging

SignServer maintains an internal audit log of all signing operations and administrative actions. By default this is written to the database.

Parameter	Default	Description
`LOG_AUDIT_TO_DB`	`true`	When `true`, audit log entries are written to the SignServer database. Set to `false` only if you are forwarding audit events through another mechanism and do not need database-backed audit logs.

YAML

signserver:
  env:
    LOG_AUDIT_TO_DB: true

Disabling database audit logging means signing events are not queryable through the SignServer Admin Web audit log viewer. Only disable this if you have an alternative audit trail in place.

Health Check

SignServer exposes a health check endpoint that reports whether the application is running and operational. It is useful for load balancers, cluster management, and external monitoring tools.

Health Check URL:

http://<host>:8080/signserver/healthcheck/signserverhealth

A healthy response returns HTTP 200 with a plain text body:

ALLOK

An unhealthy response returns HTTP 500 with a description of the problem, for example:

ERROR: Error reading configuration.

The health check verifies:

The SignServer application has started successfully
The database connection is available
Crypto Tokens marked for auto-activation have activated

The health check is available on the unencrypted HTTP port (8080) even when HTTPS is enforced for all other traffic. This makes it accessible to internal cluster components without certificate configuration.

Kubernetes Probes

Kubernetes uses three probe types to manage the SignServer pod lifecycle. All three are backed by the health check endpoint above and are pre-configured in the Helm chart with sensible defaults.

Probe	Default configuration	Purpose
Startup	`initialDelaySeconds: 20`, `periodSeconds: 10`, `failureThreshold: 30`	Gives SignServer up to 5 minutes (`20 + 30×10` seconds) to start before Kubernetes considers it failed. Prevents premature restarts during slow initialization.
Liveness	`initialDelaySeconds: 5`, `periodSeconds: 10`, `failureThreshold: 3`	Restarts the pod if SignServer stops responding, indicating a crash or unrecoverable error.
Readiness	`initialDelaySeconds: 5`, `periodSeconds: 10`, `failureThreshold: 3`	Removes the pod from the load balancer's rotation if it is not yet ready to serve traffic. Unlike liveness, a failing readiness probe does not restart the pod.

Override the defaults in your values.yaml if your environment requires different timing:

YAML

probes:
  signserver:
    startup:
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 60
    liveness:
      initialDelaySeconds: 10
      periodSeconds: 10
      failureThreshold: 3
    readiness:
      initialDelaySeconds: 10
      periodSeconds: 10
      failureThreshold: 3

Timezone

Log timestamps use the timezone of the container, which defaults to UTC. To use a different timezone, set the TZ environment variable:

YAML

signserver:
  env:
    TZ: Europe/Stockholm

Using UTC for container logs is generally recommended.