# Debugging with Logpoints in IntelliJ IDEA

A practical guide to using logpoints for efficient debugging in Java applications

- **Source:** [The JetBrains Blog](https://brifing.si/source/782eebd1-7be8-49cc-b27c-e552516691b2)
- **Published:** 2026-09-16
- **Topic:** [Software & Engineering](https://brifing.si/c/engineering)
- **Original article:** <https://blog.jetbrains.com/idea/2026/09/logpoints-walkthrough/>
- **On Brifing:** https://brifing.si/s/6d455a7a-6bd4-4646-a6fe-ed0414a00c10

## Logpoints vs traditional debugging

Logpoints offer a middle ground between println statements and breakpoints. Unlike println, they don't require code changes or redeployment. Unlike breakpoints, they don't suspend program execution. IntelliJ IDEA 2026.2 enhances logpoints with instrumentation to remove debugger overhead, making them faster while maintaining their non-intrusive nature.

## Practical debugging scenario

The article demonstrates debugging a gRPC server returning incorrect discount values. The server runs in Docker with exposed debug ports, allowing remote attachment. A client loop sends periodic requests, revealing a tenant name normalization issue where 'JetBrains' should be 'jetbrains' to apply the correct 2000 basis points discount.

## Remote debugging flexibility

IntelliJ's debugger treats local, separate environment, and remote processes identically - all communicate via sockets. This means the debugging approach works for any Java process regardless of location. The example attaches to a Docker container using the GrpcQuoteServer attach configuration, proving the technique's versatility.

## Logpoint implementation

In IntelliJ 2026.2, adding logpoints is simpler: click between executable lines and enter an expression. The example logs tenant and region at QuoteEndpoint:12. Warning: heavy computations in hot paths still impact performance. Logpoints execute in the same VM without magic optimization, though instrumentation reduces overhead.

## Progressive debugging approach

With the request loop running, developers can iteratively add and modify logpoints, watching console output for new messages. This leads to discovering the discountBpsFor() method issue where tenant name case sensitivity prevents discount application. Console navigation helps trace output back to specific logpoints or code.

## Timeout challenges with breakpoints

Regular breakpoints would suspend the server, triggering gRPC timeouts (unlike HTTP where only client times out). The client's deadline propagates to server, canceling work. Debugging must complete within timeout window. Logpoints avoid this by not suspending execution, providing needed information without timeout interference.

## Runtime modifications via logpoints

Logpoints can modify running programs through side effects. The example shows adjusting gRPC timeoutNanos in ServerImpl.createContext to 5 minutes. Multiline expressions can conditionally modify behavior (e.g., only for requests with Debug header). This demonstrates logpoints' power beyond simple logging.

## AI-assisted debugging

For developers unfamiliar with library internals, IntelliJ's ij-debugger AI agent can automate logpoint creation. It identifies where to modify runtime behavior (like deadline adjustment) without manual exploration. This makes advanced debugging techniques accessible even without deep knowledge of specific frameworks.

## Professional debugging workflow

Logpoints combine println's simplicity with breakpoints' power while avoiding their drawbacks. They enable attaching to remote processes, runtime diagnostics, on-the-fly logging adjustments, and even testing fixes without code changes. This makes them ideal for professional debugging workflows in complex systems.

## Sources covering this story

- https://blog.jetbrains.com/idea/2026/09/logpoints-walkthrough/ — 

---

_Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._