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 a program, but without modifying the code, rebuilding the application, or redeploying it, and the process does not stop execution. This makes Logpoints suitable for examining 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 via 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 run 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, separate environments, and remote hosts, so the principle of attaching does not change depending on where the Java process is running.
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, then entering the expression to be logged. The developer begins by logging information from the start of request processing, then gradually adds or modifies points as requests continue to arrive.
Tracing the call chain leads to the discountBpsFor() function. The output reveals that the tenant name arrives as 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 clicking a line in the output, 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 Are They Better Than println and Breakpoints?
The article explains that Logpoints do not pollute the code or leave behind debugging statements that could accidentally be sent to a production environment. You can also change what they log and when they log it, 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 the 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 can no longer see 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 as they execute and avoiding activation of the cancellation path caused by the timeout.
Temporarily Changing Behavior at Runtime
The article also uses Logpoints to test the effect of a fix or temporarily modify program behavior, while noting that they are primarily designed for logging rather than changing the application. Using expressions with side effects, it is possible to modify the timeout value inside the gRPC library at runtime. The example changes timeoutNanos to a five-minute timeout.
To minimize the impact of this change, it can be limited to requests carrying a Debug header, while the normal timeout remains in effect 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 expensive 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 investigation, not evidence that temporary modification is safe for all environments.
The Editorial Perspective from certi.news
The practical value here is not the addition of a new type of log message, but 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 choosing expressions and monitoring their cost, and using side effects to modify behavior should remain limited to clear, temporary debugging scenarios rather than becoming a substitute for fixing the source code.