Skip to main content
When you set a probe in VS Code, HyperProbe handles everything between your editor and your running application automatically. The VS Code extension registers your probe with the backend, the SDK agent embedded in your application instruments the target line, and captured data flows back to your editor the next time that line of code runs. No restarts, no redeployments, no paused threads.

The probe lifecycle

1

You set a probe in VS Code

Right-click any line in an open source file and choose a probe type — Snapshot, Log, Counter, Metric, or Tic & Toc. The VS Code extension sends the probe definition (file path, line number, environment, and type) to the HyperProbe backend, which persists it and makes it available to your running agents.
2

The agent picks up the probe

The SDK agent running inside your application periodically polls the broker for active probes assigned to its serviceId and environment. When the agent retrieves a new probe, it instruments the corresponding line of code using the V8 inspector (Node.js) or byte manipulation (Java). This happens at runtime, without restarting the process.
The default poll interval is 60 seconds. You can reduce it by setting syncIntervalMs in your HyperProbe.start() options.
3

Your code runs the instrumented line

The next time production execution reaches the instrumented line, the agent intercepts it. Depending on the probe type, the agent captures local variable state and the call stack (Snapshot), evaluates and emits a log string (Log), increments a counter (Counter), evaluates a numeric expression (Metric), or records a timestamp (Tic & Toc). Execution continues immediately — the agent never pauses the thread.
4

Captured data is sent to the broker

The agent batches captured events and flushes them to the broker asynchronously. This flush happens in the background, independently of your application’s request handling. The broker acknowledges receipt and forwards the data for storage.
5

Data appears in VS Code

The VS Code extension polls the backend for new captures on your active probes. When data arrives, it displays in the HyperProbe panel — variable values, the call stack, timestamps, and any other probe-specific output — ready for you to inspect without leaving your editor.

How the agent instruments code

The HyperProbe agent does not modify your source files or your deployed build artifacts. Instead, it uses the runtime’s own introspection API — the V8 inspector protocol in Node.js — to set breakpoint-like hooks on specific script locations. When execution hits an instrumented line, the hook fires, the agent reads the current local scope, and control returns to your application in microseconds. For Java applications, the agent uses bytecode manipulation to insert equivalent hooks without altering your compiled classes on disk.
Because instrumentation happens at the runtime level, HyperProbe works correctly with minified or compiled output as long as source maps are available. The agent uploads source maps at startup so the backend can resolve probe positions back to your original source files.

Safety and overhead

HyperProbe’s agent includes a safety monitor that runs continuously alongside your instrumented code. It measures two things: event loop lag and the total time spent in instrumentation per second. If either metric exceeds your configured threshold, the safety monitor automatically suspends all active probes. After a configurable cooldown period (default: 10 seconds), the agent resumes. This means a sudden traffic spike or a probe on a hot path cannot cause runaway overhead. Additional limits that apply to every capture:
  • Hit limit. Each probe stops collecting after a configured number of hits. The agent enforces this locally and the backend enforces it globally, so you never accumulate unbounded captures.
  • Data size limits. Snapshot captures are bounded by object depth, array length, string length, and property count. These defaults prevent large objects from consuming excessive memory during capture.
  • Bandwidth cap. The agent tracks the total data rate it sends to the broker and skips captures that would exceed the limit.
Probes on extremely high-frequency lines (millions of calls per second) will be subject to rate limiting and may skip captures. Use the hitsPerSec option to tune the capture rate, or use a Counter probe instead of a Snapshot for hot paths.

Key components

These are the parts of HyperProbe you interact with directly:
ComponentWhat it does
VS Code extension (hyperprobe-extension)UI for setting, viewing, and managing probes
Node.js SDK (@hyperprobe/node-sdk)Agent that runs inside your Node.js application
Java SDKJVM agent attached via -javaagent flag
.hprc fileProject-level config that maps your source files to a serviceId
HyperProbeOptionsConfiguration object passed to HyperProbe.start()
The broker and backend that route data between your agent and VS Code are operated as part of your HyperProbe deployment. You point the SDK at the broker URL and the extension at the backend URL in their respective configuration.

What HyperProbe does not do

  • It does not pause your application or block any threads during capture.
  • It does not require you to modify your source code beyond adding the HyperProbe.start() call.
  • It does not require a restart to activate or deactivate probes — changes take effect on the next agent sync cycle.
  • It does not store sensitive values by default. Keys matching common patterns (password, secret, token, authorization, cookie, key, signature) are automatically redacted from captured data.