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; the process also does not pause execution. This makes Logpoints suitable for inspecting services running locally, inside a Docker container, or on a remote host.
The Problem Addressed by the Example
The example is based on 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 of $100.00 with discount_bps=0, while the expected value is $80.00 with discount_bps=2000.
The server is launched 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 based 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 and 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.
Following 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 when 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. What they record and when they record it can also be changed, including sampling recurring 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 that timeout can be propagated to the server. When the debugger pauses 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 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, it is possible to modify the timeout value inside the gRPC library 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 preserved for all 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 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 diagnostics to a layer that can be modified at runtime. This is particularly important for remote services or services involving race conditions or timeouts, where pausing execution may conceal the problem itself. At the same time, the approach requires discipline in selecting 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.