Skip to main content
Weaviate Docs (migrated from docs.weaviate.io) Docs

Search documentation

Type to search this documentation.

On this pageOverview

Logging

Weaviate produces structured logs that provide visibility into system operations, help with troubleshooting, and support security auditing.

Logs can be used to debug issues, monitor operational health, track authorization decisions, identify slow queries, and understand system behavior.

For example, the following logs showing system initialization:

JSON
{"action":"startup","build_git_commit":"5f0048c","build_go_version":"go1.25.5","build_image_tag":"v1.35.1","build_wv_version":"1.35.1","default_vectorizer_module":"none","level":"info","msg":"the default vectorizer modules is set to \"none\", as a result all new schema classes without an explicit vectorizer setting, will use this vectorizer","time":"2026-01-06T15:51:32Z"}
{"action":"grpc_startup","build_git_commit":"5f0048c","build_go_version":"go1.25.5","build_image_tag":"v1.35.1","build_wv_version":"1.35.1","level":"info","msg":"grpc server listening at [::]:50051","time":"2026-01-06T15:51:34Z"}
{"action":"restapi_management","build_git_commit":"5f0048c","build_go_version":"go1.25.5","build_image_tag":"v1.35.1","build_wv_version":"1.35.1","level":"info","msg":"Serving weaviate at http://[::]:8080","time":"2026-01-06T15:51:34Z","version":"1.35.1"}

The "Serving weaviate at" message indicates the server is ready to accept requests. If there were issues during startup, error logs would provide details to help diagnose the problem.

Logging can be configured using environment variables. Many of these environment variables can also be configured with runtime configuration overrides, which allow you to change settings without restarting Weaviate.

The LOG_LEVEL environment variable controls the verbosity of Weaviate's logging output. The following log levels are available (from least to most verbose), corresponding to levels defined by the logrus logging library:

Level Description
panic Highest level of severity. Logs and then calls panic with the message passed to Debug, Info, ...
fatal Logs and then calls logger.Exit(1). It will exit even if the logging level is set to Panic.
error Used for errors that should definitely be noted. Commonly used for hooks to send errors to an error tracking service.
warning Non-critical entries that deserve eyes.
info General operational entries about what's going on inside the application.
debug Usually only enabled when debugging. Very verbose logging.
trace Designates finer-grained informational events than the Debug.

The LOG_FORMAT environment variable controls how log entries are formatted. Weaviate supports two formats, json and text:

Shell
LOG_FORMAT=json

JSON format produces structured logs that are ideal for parsing by log aggregation systems:

JSON
{"action":"startup","build_git_commit":"5f0048c","build_go_version":"go1.25.5","build_image_tag":"v1.35.1","build_wv_version":"1.35.1","default_vectorizer_module":"none","level":"info","msg":"the default vectorizer modules is set to \"none\", as a result all new schema classes without an explicit vectorizer setting, will use this vectorizer","time":"2026-01-06T15:51:32Z"}
{"action":"authorize","build_git_commit":"5f0048c","build_go_version":"go1.25.5","build_image_tag":"v1.35.1","build_wv_version":"1.35.1","component":"RBAC","level":"info","msg":"","permissions":[{"resource":"[Domain: collections, Collection: TempCollection]","results":"success"}],"rbac_log_version":2,"request_action":"D","source_ip":"192.168.65.1","time":"2026-01-06T15:51:36Z","user":"root-user"}

Use JSON format when:

  • Using log aggregation tools (Elasticsearch, Loki, CloudWatch, etc.)
  • Automating log analysis or alerting
  • Running in production environments

Text format produces human-readable logs suitable for direct viewing:

text
time="2026-01-06T15:54:58Z" level=info msg="the default vectorizer modules is set to \"none\", as a result all new schema classes without an explicit vectorizer setting, will use this vectorizer" action=startup build_git_commit=5f0048c build_go_version=go1.25.5 build_image_tag=v1.35.1 build_wv_version=1.35.1 default_vectorizer_module=none
time="2026-01-06T15:55:01Z" level=info action=authorize build_git_commit=5f0048c build_go_version=go1.25.5 build_image_tag=v1.35.1 build_wv_version=1.35.1 component=RBAC permissions="[map[resource:[Domain: collections, Collection: TempCollection] results:success]]" rbac_log_version=2 request_action=D source_ip=192.168.65.1 user=root-user

Use text format when:

  • Viewing logs directly in the terminal during development
  • Debugging issues locally
  • Easier visual scanning is preferred over machine parsing

A log entry whose cause has a documented fix carries a docs_url field. The link is a stable short id, https://docs.weaviate.io/e/<id>, that resolves to the entry for that message in the error message reference, where the cause and the fix are on one page:

JSON
{"action":"tenant_activation_lazy_load_shard","docs_url":"https://docs.weaviate.io/e/core-mem001","level":"error","msg":"loading shard \"t1\" failed: memory pressure: cannot init shard: not enough memory mappings","shard":"t1","time":"2026-08-25T09:53:26Z"}

The field is separate from the message, so alerts and filters that match on message text keep working, and in JSON logs you can select on it directly. The error returned to the client for the same failure carries the same link at the end of its message, as (see https://docs.weaviate.io/e/core-mem001). Added in v1.40.

When telemetry is enabled, the link also carries the cluster id as ?clusterid=<uuid>, the same id telemetry reports. The docs page shows it back to you so you can quote it to support, and does nothing else with it. With DISABLE_TELEMETRY=true the link is bare.

Weaviate also logs a banner with the version, a link to Improve your cluster and this node's /v1/meta URL shortly after startup, and again every BANNER_INTERVAL (24 hours by default). The art is fetched from https://weaviate.io/banner/v1.json when it can be, and when that file carries a message, such as a release announcement, the banner prints it as a ► News: line (at most three lines). The banner runs only while telemetry is enabled, because it fetches its art from weaviate.io, so a cluster with DISABLE_TELEMETRY=true never logs one. Set DISABLE_STARTUP_BANNER to turn it off on a cluster that would.

Weaviate logs can be accessed using standard container logging commands. For example:

Docker:

Bash
# View logs
docker logs <container-name>

# Follow logs in real-time
docker logs -f <container-name>

For more Docker logging options, see the Docker logs documentation.

Kubernetes:

Bash
# View logs
kubectl logs <pod-name>

# Follow logs in real-time
kubectl logs -f <pod-name>

For more Kubernetes logging options, see the kubectl logs documentation.

Weaviate can log queries that exceed a specified duration threshold. This is useful for identifying performance bottlenecks.

To enable slow query logging, set these environment variables:

Shell
QUERY_SLOW_LOG_ENABLED=true
QUERY_SLOW_LOG_THRESHOLD=2s

When enabled, queries exceeding the threshold will be logged at the configured log level, allowing you to identify and optimize slow operations.

For per-query timing breakdowns on demand (without configuring log thresholds), see Query profiling.

For multi-tenant collections, you can configure the log level for tenant read and write activity.

Shell
TENANT_ACTIVITY_READ_LOG_LEVEL=info
TENANT_ACTIVITY_WRITE_LOG_LEVEL=info

When RBAC authorization is enabled, Weaviate automatically logs authorization decisions and role management operations for audit purposes. These logs capture:

  • User making the request
  • Action being authorized or performed
  • Authorization decision (allowed or denied)
  • User groups (if applicable)
  • Source IP address (optional)
  • Resource being accessed

Authorization decision logs are generated for RBAC-based authorization evaluations. These logs record both successful and denied authorization attempts, making them valuable for security auditing and troubleshooting access issues.

Key fields:

  • user - The user making the request
  • request_action - The action being attempted (see action codes below)
  • permissions.resource - The resource being accessed
  • permissions.results - Authorization outcome (success or denied)
  • source_ip - IP address of the client (if available, configurable via AUTHORIZATION_RBAC_IP_IN_AUDIT_LOG_DISABLED env var)

Example successful authorization:

In this example, user root-user successfully deleted the TempCollection:

JSON
{
  "action": "authorize",
  "build_git_commit": "5f0048c",
  "build_go_version": "go1.25.5",
  "build_image_tag": "v1.35.1",
  "build_wv_version": "1.35.1",
  "component": "RBAC",
  "level": "info",
  "msg": "",
  "permissions": [
    {
      "resource": "[Domain: collections, Collection: TempCollection]",
      "results": "success"
    }
  ],
  "rbac_log_version": 2,
  "request_action": "D",
  "source_ip": "192.168.65.1",
  "time": "2026-01-06T15:51:36Z",
  "user": "root-user"
}

The request_action: "D" indicates a Delete operation, and results: "success" confirms the user had the necessary permissions.

See this page more information on how to manage RBAC permissions.

Example denied authorization:

When authorization is denied, the log entry differs in several ways. Here is a denied authorization example:

JSON
{
  "action": "authorize",
  "build_git_commit": "5f0048c",
  "build_go_version": "go1.25.5",
  "build_image_tag": "v1.35.1",
  "build_wv_version": "1.35.1",
  "component": "RBAC",
  "level": "error",
  "msg": "authorization denied",
  "permissions": [],
  "rbac_log_version": 2,
  "request_action": "D",
  "source_ip": "192.168.65.1",
  "time": "2026-01-08T16:17:47Z",
  "user": "readonly-user"
}

In this example, user readonly-user attempted to delete a collection but lacked the necessary permissions.

RBAC role creation and deletion operations are also logged for audit purposes:

Example role creation:

JSON
{
  "action": "create_role",
  "build_git_commit": "5f0048c",
  "build_go_version": "go1.25.5",
  "build_image_tag": "v1.35.1",
  "build_wv_version": "1.35.1",
  "component": "RBAC",
  "level": "info",
  "msg": "role created",
  "permissions": [
    {
      "action": "read_collections",
      "collections": {"collection": "*"}
    },
    {
      "action": "read_data",
      "data": {"collection": "*", "tenant": "*"}
    }
  ],
  "roleName": "ReaderRole",
  "time": "2026-01-06T15:52:58Z",
  "user": "root-user"
}

Example role deletion:

JSON
{
  "action": "delete_role",
  "build_git_commit": "5f0048c",
  "build_go_version": "go1.25.5",
  "build_image_tag": "v1.35.1",
  "build_wv_version": "1.35.1",
  "component": "RBAC",
  "level": "info",
  "msg": "role deleted",
  "roleName": "ReaderRole",
  "time": "2026-01-06T15:53:31Z",
  "user": "root-user"
}

These audit logs are automatically generated when RBAC is enabled - no additional configuration is required.

Have a question or feedback? Here's how to reach us.

Suggest an edit

Propose a replacement for this page. The site team reviews it before applying any changes.

Export
Documentation menu