Logpoints
A logpoint is a non-suspending breakpoint that writes debug messages to the console when it is hit.
Logpoints help you with:
Keeping debug logging clean and centralized instead of scattering
println()calls.Getting insight into timing-sensitive sections of the program without pausing execution. Logpoints can be added or modified while the program is running, without restarting it or using HotSwap.
Debugging libraries or other code that you cannot edit.
Accessing fields and methods that are otherwise inaccessible, for example, calling a private method of a third-party class without reflection.
Navigating from log entries back to the code that produced them and getting additional runtime information, such as the thread's stack trace when the logpoint was hit.
Collecting runtime evidence with an AI agent, as described in Agentic debugging.
Create logpoints
Click the gutter between any two executable lines. A yellow circle icon appears.
Alternatively, place the caret on a line and press Ctrl+Alt+F8 to add a logpoint above it.
Since the gutter is also used for breakpoints, you can hold a modifier key while clicking to restrict which type is created:
Ctrl: Add breakpoints only
Shift: Add logpoints only
Enter the expression to log. With this expression, you can capture any state that is accessible at this point in the program.
Convert an existing breakpoint to a logpoint
Right-click an existing breakpoint in the gutter, then click More, or press Ctrl+Shift+F8.
Configure the logging options.
Clear the Suspend option if you want the breakpoint to log output without pausing the program. Leave Suspend selected if you want to log output and stop at the same breakpoint.
Add logpoints using command completion
In Java and Kotlin files, you can add a logpoint for an expression directly in the editor by using command completion.
Place the caret after the expression that you want to log and type
.or...Select Add Logpoint. To filter the list, type
logorprint.If several expressions end at the caret, select the one to log.
IntelliJ IDEA adds a logpoint above the current line with the selected expression.
In Java, if the expression is on a separate line, for example, users.size(), IntelliJ IDEA removes this line and logs the expression with a logpoint instead.
Logging options
When a breakpoint is hit, the following can be logged to the console:
"Breakpoint hit" message: a log message like
Breakpoint reached at ocean.Whale.main(Whale.java:5).Stack trace: the stack trace for the current frame. This is useful if you want to check what paths have led to this point without interrupting the program execution.
If the task was scheduled from another thread, the stack trace also includes asynchronous frames from that thread. To display these frames, make sure the Instrumenting agent option under is enabled (enabled by default).
To get asynchronous frames from a remote process, add the debugger agent to the remote JVM.
Evaluate and log: the result of an arbitrary expression, for example,
"Initializing"orusers.size().The expression disregards any access modifiers and is evaluated in the context of the line where the breakpoint is set.
The result of the expression is taken from the return statement. When there is no return statement, the result is taken from the last line of code, which doesn't have to be an expression: a literal works too. This can be used to produce a custom message or to keep track of some values as the program executes.
When evaluating expressions, make sure you are aware of their possible side effects as they may potentially affect the behavior and the result of the program.
Navigation and stack traces
Logpoints in IntelliJ IDEA let you navigate to the corresponding code and find out the actual code path that was taken when the logpoint was hit.
Click a log entry that was produced by a logpoint in IntelliJ IDEA, then select Open. Alternatively, click it while holding Ctrl.
The corresponding code opens in the editor, and the Stack Trace tab opens with the thread's stack trace from when the logpoint was hit.
Narrow the logging
Because logpoints are regular breakpoints with logging options, you can combine them with other breakpoint properties.
- Condition
Add a condition to log output only when a Boolean expression evaluates to
true. The condition needs to be valid at the line where the breakpoint is set.- Pass count
Specifies that the breakpoint should work only after it has been hit a certain number of times. This is useful for debugging scenarios that involve suspending the application in long-running loops or for selectively logging frequent events.
Once the count completes, it resets and starts again. This means that if Pass count is set to
10, the breakpoint will work every tenth time it is hit.If both Pass Count and Condition are set, IntelliJ IDEA first satisfies the condition and then checks for Pass Count.
- Filters
Use filters to restrict the breakpoint to specific classes, object instances, or caller methods. This is useful when the same code is reached from many places and you only need log output for one path.
- Dependent breakpoints
A non-suspending breakpoint can act as a trigger for another breakpoint in Disable until hitting the following breakpoint. Use this when a later breakpoint should become active only after a specific code path is reached.
For the complete list of breakpoint properties, refer to Configure breakpoints' properties.
Logpoint icons
Non-suspending breakpoints use a different gutter icon from regular suspending breakpoints.
Line | Method | Field | Exception | |
|---|---|---|---|---|
Non-suspending |
|
|
| |
Verified non-suspending |
|
|
|
Manage logpoints
Logpoints appear in the same Breakpoints dialog as other breakpoints. From there, you can disable, mute, remove, describe, and group them together with the rest of your breakpoint setup.
For more information, refer to Breakpoints.