In an article written by Igor Kulakov, JetBrains presents a practical guide to using Logpoints in IntelliJ IDEA 2026.2 to diagnose Java application errors at runtime. The idea is similar to adding println statements to the program, but without modifying the code, rebuilding the application, or redeploying it, and the process does not stop execution. This makes it suitable for inspecting services running locally, inside a Docker container, or on a remote host.
The Problem Addressed by the Example
The example uses a client and server communicating over gRPC. The server returns an incorrect discount value for some tenants. When a request is sent for the JetBrains tenant and the EMEA region, the console shows a price value of $100.00 with discount_bps=0, while the expected value is $80.00 with discount_bps=2000.
The server is started using Docker with its listening and debugging ports exposed, and the client sends requests periodically. After starting the server and client, the developer can attach the IntelliJ IDEA debugger to the process even if it was not started from a local debugging session. According to the explanation, the debugger communicates through a socket in local cases, separated environments, and remote hosts, so the principle of attaching does not change depending on where the Java process runs.
How Do Logpoints Reveal the Cause of the Error?
In IntelliJ IDEA 2026.2, a Logpoint can be created more quickly by clicking in the editor gutter between two executable lines and then entering the expression to be logged. The developer begins by recording information from the start of request processing, then gradually adds or modifies points while requests continue to arrive.
Tracing the call chain leads to the discountBpsFor() function. The output reveals that the tenant name arrives in the form JetBrains, while the comparison logic expects the value jetbrains. The output also shows that the discount was not applied, meaning that the code branch returning 2,000 basis points was not executed. The example suggests fixing the comparison by using equalsIgnoreCase, then testing the expected behavior.
The benefit is not limited to displaying text in the console; when a line in the output is clicked, IntelliJ IDEA can navigate to the Logpoint or the related code section. This navigation also works with println statements if the process is running under the IntelliJ IDEA debugger.
When Do They Outperform println and Breakpoints?
The article explains that Logpoints do not pollute the code or leave behind debugging statements that might accidentally be sent to a production environment. What they record and when they record it can also be changed, including sampling repeated events, adding logging inside dependencies, and avoiding costly redeployments.
Traditional breakpoints may be unsuitable when stopping the service is part of the problem. In the example, the client sets a timeout for a gRPC request, and this timeout can be propagated to the server. When the debugger stops the server, the timeout expires and the request moves to the cancellation path, so the developer no longer sees the state that led to the error. Using a breakpoint then requires sending requests one at a time and working within the timeout window.
By contrast, Logpoints provide information without suspending the server, allowing requests to be monitored while they execute and avoiding activation of the cancellation path caused by a timeout.
Temporarily Modifying Behavior at Runtime
The article also uses Logpoints to test the effect of a fix or temporarily modify the program’s behavior, while noting that they are primarily designed for logging rather than changing the application. Using expressions with side effects, the timeout value inside the gRPC library can be modified at runtime. The example shows changing timeoutNanos to a timeout of five minutes.
To reduce the impact of this change, it can be limited to requests carrying a Debug header, while the normal timeout is retained for other requests. The example includes multiline logic that reads the header and resets the timeout only when its value matches, then displays the message Timeout reset to confirm that the branch was visited.
What Should You Be Careful About?
JetBrains warns against placing heavy computations in hot paths because logging expressions are executed inside the virtual machine itself and are not free in terms of time. It notes that IntelliJ IDEA 2026.2 removes the overhead caused by the debugger through instrumentation, but this does not eliminate the cost of expressions or intensive logging.
The article also points to the possibility of using the Mark Object feature to access arbitrary objects from a Logpoint expression field, as well as the attached ij-debugger AI agent skill, which can identify where the timeout is read and create an expression targeting test requests. This remains an alternative to manual understanding, not evidence that temporary modification is safe for all environments.
The Editorial View from certi.news
The practical value here is not in adding a new type of log message, but in moving diagnosis to a layer that can be modified at runtime. This is particularly important for remote services or services with race conditions or timeouts, where stopping execution may hide the problem itself. At the same time, the approach requires discipline when selecting expressions and monitoring their cost, and using side effects to modify behavior should remain confined to clear, temporary debugging scenarios rather than becoming a substitute for fixing the source code.