Keycloak Log Level
You set the keycloak log level through server startup settings or host variables. This setting controls how much detail the identity server writes to its log files. Platform teams often turn up log detail when login flows fail. They want to see token exchanges, user group checks, and directory lookups. Still, high log levels can write secrets and user details straight into plain text files. Broad admin roles let too many staff members read those raw server logs. How the keycloak log level work
Keycloak + Log Aggregation & Correlation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set the keycloak log level through server startup settings or host variables. This setting controls how much detail the identity server writes to its log files. Platform teams often turn up log detail when login flows fail. They want to see token exchanges, user group checks, and directory lookups. Still, high log levels can write secrets and user details straight into plain text files. Broad admin roles let too many staff members read those raw server logs.
How the keycloak log level works
The identity server splits its output into different parts and severity tiers. A root setting sets the baseline for the whole server run. Teams can also tune specific categories for user logins, database storage, or network events. Low detail tiers only record server crashes or major errors. Standard tiers write startup notes and normal system state changes. High detail tiers write out every step of a user login check.
When a user tries to log in, the server runs through several internal checks. The logging engine checks the active tier before it writes a line. If the tier is high, the server records the whole request and response flow. Teams send these text lines to local files or central log tools. Server admins can adjust these settings at startup or through runtime management tools. Good log hygiene means keeping the root tier quiet during normal daily runs.
Choosing the right log tier for daily operations
Most production teams keep the root tier at a standard info level. They only raise specific login categories when a single app fails to connect. Turning on debug mode across the whole server creates huge text files fast. That flood of text slows down disk writes and fills up storage volumes. Even worse, debug output can capture raw tokens, passwords, or private user fields. Anyone with read permissions on the log store can see that sensitive data.
Teams should scope debug tiers to one internal package at a time. Once the team fixes the login bug, they must lower the tier right away. Central log collectors should also scrub sensitive strings before saving the lines. Masking rules can rewrite emails, phone numbers, card numbers, and national IDs in results. This keeps private user details out of shared search tools and alert messages.
Keycloak + Log Aggregation & Correlation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity server logs solve and what they miss
Tuning your identity server logs helps you fix broken login flows and group mappings. The server log tells you who logged in and which token they got. It also shows when a user fails a password check or multi-factor prompt. This solves the first half of the audit puzzle for security teams.
Still, the identity server stops watching once the user gets a valid token. The login log only decides who enters an app or stack system. It never sees what individual SQL statements, shell commands, or API requests do next. A developer might log in fine and then run a destructive database query. A support engineer might pull thousands of customer rows during a normal session. Identity logs show a clean login, while the actual data risk goes unrecorded. Teams need session-level controls that check every command and mask sensitive results in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can I change the log level without a server restart?
Many container setups need a quick restart to read new startup variables. Some runtime management interfaces let admins update category tiers while the server runs.
Why do debug logs create a security risk in production?
Debug tiers often write raw login requests, session tokens, and user attributes to disk. Staff with log viewer roles could read those tokens and hijack active sessions.
Do identity logs satisfy full database audit requirements?
No, identity logs only prove that a user signed in at a specific time. Complete audits require a record of every query or command run during the session.