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:
{"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.
Configure Logging
Section titled “Configure Logging”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.
Log Level
Section titled “Log Level”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. |
Log Format
Section titled “Log Format”The LOG_FORMAT environment variable controls how log entries are formatted. Weaviate supports two formats, json and text:
LOG_FORMAT=jsonJSON format (default)
Section titled “JSON format (default)”JSON format produces structured logs that are ideal for parsing by log aggregation systems:
{"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
Section titled “Text format”Text format produces human-readable logs suitable for direct viewing:
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-userUse text format when:
- Viewing logs directly in the terminal during development
- Debugging issues locally
- Easier visual scanning is preferred over machine parsing
Messages with a docs link
Section titled “Messages with a docs link”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:
{"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.
Accessing Logs
Section titled “Accessing Logs”Weaviate logs can be accessed using standard container logging commands. For example:
Docker:
# 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:
# 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.
Special-Purpose Logging
Section titled “Special-Purpose Logging”Slow Query Logging
Section titled “Slow Query Logging”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:
QUERY_SLOW_LOG_ENABLED=true
QUERY_SLOW_LOG_THRESHOLD=2sWhen 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.
Tenant Activity Logging
Section titled “Tenant Activity Logging”For multi-tenant collections, you can configure the log level for tenant read and write activity.
TENANT_ACTIVITY_READ_LOG_LEVEL=info
TENANT_ACTIVITY_WRITE_LOG_LEVEL=infoAuthorization Audit Logging
Section titled “Authorization Audit Logging”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
Section titled “Authorization decision logs”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 requestrequest_action- The action being attempted (see action codes below)permissions.resource- The resource being accessedpermissions.results- Authorization outcome (successordenied)source_ip- IP address of the client (if available, configurable viaAUTHORIZATION_RBAC_IP_IN_AUDIT_LOG_DISABLEDenv var)
Example successful authorization:
In this example, user root-user successfully deleted the TempCollection:
{
"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:
{
"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.
Role management logs
Section titled “Role management logs”RBAC role creation and deletion operations are also logged for audit purposes:
Example role creation:
{
"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:
{
"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.
Further resources
Section titled “Further resources”- Configuration: Monitoring (Prometheus metrics)
- Configuration: Environment variables
- Configuration: RBAC
- Troubleshooting
Questions and feedback
Section titled “Questions and feedback”Have a question or feedback? Here's how to reach us.