Application Logs (On-Premises)

This page covers self-hosted Docker installs, both Standalone and High Availability. If your deployment runs in an Azure subscription instead, see Application Logs.

Everything stays on your host. There is nothing to install and no log agent to configure: the platform writes to standard output and Docker keeps it for you.

Where your logs live

The application, the web interface, and the workflow workers all run in the docaifabric container and log to standard output. Docker's logging driver captures that stream, and docker compose logs reads it back. Redis logs the same way in its own container.

The application does not write a separate log file into the data volume, so docker compose logs (or your own log driver, if you configured one) is the single source of truth.

One source lives outside the platform logs: the processing history of each transaction, which you read in the product itself. Open a transaction to see which steps ran, in what order, and how long each took. For a single failed document that is usually faster than searching the container log.

Reading the logs

Run these from the folder that holds your docker-compose.yml.

# Follow the live stream
docker compose logs -f docaifabric

# Just the recent tail
docker compose logs --tail=200 docaifabric

# Only what happened in the last 30 minutes, with timestamps
docker compose logs --since 30m --timestamps docaifabric

# Errors and warnings only
docker compose logs docaifabric | grep -Ei "error|warn|traceback"

# Everything about one transaction (paste its ID)
docker compose logs docaifabric | grep "<transaction-id>"

# The job queue
docker compose logs -f redis

If you started the container without Compose, find its name with docker ps and use docker logs -f <container-name> instead.

On a High Availability install each node keeps its own container logs, so run the command on the node you are investigating, or point your existing log collector at the Docker socket to gather all nodes in one place.

More detail when you need it

Set LOG_LEVEL=DEBUG in your .env and restart with docker compose up -d. This is verbose, so switch it back to the default once you have what you need.

What to look for

Every line is prefixed with a level (INFO, WARNING, ERROR). Start from the last ERROR block and read the few lines above it: they normally name the transaction or the processing step that failed. Useful landmarks at startup are Model registry initialized and Started ... workflow worker(s); if you do not see them, the container came up without a working model configuration.

Keeping the log from growing forever

By default Docker's json-file driver never trims the log, which on a long-lived install can quietly fill the disk. Cap it per service in your docker-compose.yml:

services:
  docaifabric:
    # ...
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

That keeps at most five 50 MB files (250 MB) per container. Apply the same block to redis, then run docker compose up -d for it to take effect. If your organisation already runs a central log platform, point its Docker collector at the host instead and it will pick the streams up as they are.

Sharing logs with support

Save a recent excerpt to a file and send it to us:

docker compose logs --no-color --tail=2000 docaifabric > docai-logs.txt

Two thousand lines around the failure is almost always enough. Please include the transaction ID and the approximate time the problem occurred, so we can find the right block quickly. Logs may contain document file names and user email addresses, so review the file before sharing it if that matters in your environment.