Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Kevin2523/nextAuditAi/llms.txt

Use this file to discover all available pages before exploring further.

An audit platform is only as trustworthy as its own operational health. When FleetDM stops reporting, osquery results go silent, or a vulnerability scan skips its scheduled run, teams lose the continuous visibility that compliance workflows depend on. This page explains how to verify that every service in the NextAudit AI stack is running correctly, where logs are written, and how to observe ongoing vulnerability scan activity — so that gaps in coverage are caught before they become audit findings.

​
Built-in health checks

Every stateful service in the stack declares a Docker health check. Docker evaluates each check on a fixed interval and marks the container healthy, unhealthy, or starting. Services that depend on each other (for example, fleet depends on mysql and redis) will not start until their dependencies are healthy.

​
Fleet

Fleet exposes a dedicated /healthz endpoint that returns HTTP 200 when the server is ready. 
healthcheck:
  test: ["CMD", "wget", "-qO-", "http://127.0.0.1:${FLEET_SERVER_PORT}/healthz"]
  interval: 10s
  timeout: 5s
  retries: 12
ParameterValue
interval10 s
timeout5 s
retries12

​
PostgreSQL

PostgreSQL uses pg_isready to verify the database accepts connections for the configured user and database name. 
healthcheck:
  test: ["CMD-SHELL", "pg_isready -U $POSTGRES_USER -d $POSTGRES_DB"]
  interval: 5s
  timeout: 5s
  retries: 10
ParameterValue
interval5 s
timeout5 s
retries10
PostgreSQL uses a shorter interval (5 s) than the other services because Flowise blocks on the service_healthy condition — a faster check reduces startup latency for the AI layer.

​
MySQL

MySQL is checked with mysqladmin ping, which authenticates with the runtime user credentials. 
healthcheck:
  test:
    [
      "CMD-SHELL",
      "mysqladmin ping -h 127.0.0.1 -u$$MYSQL_USER -p$$MYSQL_PASSWORD --silent || exit 1"
    ]
  interval: 10s
  timeout: 5s
  retries: 12
ParameterValue
interval10 s
timeout5 s
retries12

​
Redis

Redis responds to a PING command over the CLI. The check is simple and fast. 
healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 5s
  retries: 12
ParameterValue
interval10 s
timeout5 s
retries12

​
Checking service status

Use docker compose ps to see the current state and health of every container at a glance. 
docker compose -f src/ai-sentinel/docker-compose.dev.yml ps
Pipe docker compose ps output through grep -v healthy to surface any container that is not yet reporting a healthy status.

​
Fleet log configuration

Fleet writes two separate log streams to the filesystem. Both paths are configured via environment variables and written inside the logs volume, which is mounted at /logs in the Fleet container.
Environment variablePurpose
FLEET_FILESYSTEM_STATUS_LOG_FILEPath for osquery status logs (agent lifecycle events)
FLEET_FILESYSTEM_RESULT_LOG_FILEPath for osquery result logs (query output from enrolled hosts)
FLEET_LOGGING_JSONSet to true to emit structured JSON logs instead of plaintext
The FLEET_OSQUERY_STATUS_LOG_PLUGIN variable controls which log destination receives osquery status messages. When set to filesystem, logs flow to the path defined by FLEET_FILESYSTEM_STATUS_LOG_FILE. 
# Fleet container volume binding
volumes:
  - logs:/logs
Enable FLEET_LOGGING_JSON=true in any environment where logs are forwarded to an external aggregator (such as Loki, Elasticsearch, or CloudWatch Logs). Structured JSON makes field extraction reliable without custom parsing rules.

​
Vulnerability scan monitoring

Fleet runs scheduled vulnerability scans against the enrolled host inventory. Two environment variables govern how often scans run and where the vulnerability database is stored.
Environment variablePurpose
FLEET_VULNERABILITIES_PERIODICITYHow frequently Fleet checks for new vulnerabilities (e.g., 1h)
FLEET_VULNERABILITIES_DATABASES_PATHFilesystem path where Fleet stores its vulnerability database
FLEET_VULNERABILITIES_CURRENT_INSTANCE_CHECKSEnables vulnerability checks on the current Fleet instance
The vulnerability database is stored in the vulndb volume, which is mounted at $FLEET_VULNERABILITIES_DATABASES_PATH inside the Fleet container: 
volumes:
  - vulndb:${FLEET_VULNERABILITIES_DATABASES_PATH}
Monitor the vulndb volume size over time. Fleet downloads CVE data on each periodicity cycle; a stale or unexpectedly small database may indicate network connectivity issues preventing the download.

Build docs developers (and LLMs) love

Get started for freeTalk to us