Keycloak Log Levels
You set up keycloak log levels by defining root and category severity rules at startup. These settings control how much detail the identity server writes to your log output. Most teams start with standard output logs and raise detail when login flows fail. Still, broad admin roles or wide debug logs can expose tokens and secrets to staff. How keycloak log levels work in your setup The identity server groups its internal events into named categories and severity tiers. You can set a main root
Keycloak + Log Aggregation & Correlation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up keycloak log levels by defining root and category severity rules at startup. These settings control how much detail the identity server writes to your log output. Most teams start with standard output logs and raise detail when login flows fail. Still, broad admin roles or wide debug logs can expose tokens and secrets to staff.
How keycloak log levels work in your setup
The identity server groups its internal events into named categories and severity tiers. You can set a main root level that applies to the whole server run. Common tiers range from fatal errors and warnings down to info, debug, and trace. Info level shows startup events and high-level operational steps during a normal server run.
Debug and trace levels print deep step-by-step details for specific modules or login checks. Instead of turning on debug across the entire server, teams target single package categories. For example, you can raise log detail just for user login flows or token exchanges. This targeted setup keeps your main log storage clean and prevents disk space issues.
You can send these logs to the console, local files, or central log tools. Structured JSON output helps security teams parse fields and search for failed login attempts. Admins also enable separate user event listeners to track login success and password resets. Admin event logs record when a user with high permissions changes a realm rule.
Choosing the right categories for identity checks
When a single sign-on flow fails, the standard info logs rarely show the root cause. You need to adjust specific categories that handle identity brokering, LDAP sync, or token signing. Turning on debug for the login category shows how the server evaluates each browser step. If a user directory sync fails, directory categories show the exact bind or query failure.
Once you fix the broken login flow, you should lower the category level back down. Leaving trace or debug levels running in production writes huge volumes of text every second. High log volume slows down server responses and increases your central log storage bills. Even worse, trace output can write raw headers, session cookies, or personal emails to disk.
Anyone who can read those log files might find active credentials or private user data. Teams must restrict who can change log settings and who can read raw log streams. Good role setup splits identity admins from the engineers who only view basic app health.
Keycloak + Log Aggregation & Correlation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native identity logs solve and what they miss
Tuning your identity server logs gives you clear visibility into who signed in and when. You can see which identity provider verified the user and which roles they received. These logs also prove when an admin changed a client setting or updated a realm. For login issues and role checks, native server logs do their job very well.
Still, identity logs stop at the moment the user gets a valid session or token. The identity server decides who logs in, not what happens inside your systems afterward. Once an engineer connects to a production database or server, identity logs go blind. They do not record the individual SQL statements, shell commands, or API requests in flight.
If an engineer runs a broad select query, the identity log shows nothing about it. It also cannot rewrite sensitive fields like card numbers, phone numbers, or national IDs. To control and audit real actions, teams must inspect commands and queries at runtime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between system logs and user event logs?
System logs record internal server health, startup steps, and low-level processing errors for engineers. User event logs track specific identity actions like logins, logouts, token refreshes, and password changes.
Is it safe to run debug or trace levels in production?
Running debug or trace across the whole server in production is risky and slow. Only enable debug on one narrow category for a short time to fix an issue.
Do identity server logs show what users do inside connected databases?
No, the identity server only logs the login check and token creation steps. It cannot see or log the queries and commands a user runs after logging in.