HyperProbe: AI On-Call Agent Finds Root Cause in Under 10 Minutes

Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

HyperProbe (YC S26) is an AI on-call agent that automatically investigates production incidents. It picks up alerts from PagerDuty, Datadog, or Slack, reads logs and traces, and places read-only virtual breakpoints on suspect lines in running services. This captures exact variable state without redeployment or service interruption, reducing time to root cause from hours to minutes. It supports Node.js, TypeScript, Java, Kotlin, and Python, and integrates with coding agents like Cursor and Claude Code.

The fix takes minutes. Finding it takes hours, because the value that explains failure is never logged.
  1. tizerluo

    Two things I would want to know before pointing this at a hot service: (1) the overhead budget — when a probe lands on a hot path, is capture sampled or capped per hit, and what p99 latency delta have you measured under load? (2) failure isolation — if probe evaluation itself throws (weird object shape, getter with side effects, huge captured value to serialize), is it contained so it cannot take down the request it is observing? In-process agents live or die by staying boring under worst-case conditions.

  2. doublerebel

    How is HyperProbe different from existing tools like AppSignal, Rollbar, and Embrace? Such very mature tools exist that auto-instrument, collect variables from the call stack, and pinpoint error causes.

    > Every log-and-trace tool hands the agent data that already exists and asks it to reason backward to what probably happened

    If the app is using a decent instrumentation tool, the data shows what 'actually' happened, not what 'probably' happened.

    > "checkout returns 200 but some users are seeing their order fail, find out why."

    Does this tool only exist to shore up poor system design? Failing orders at any e-commerce business I've worked with, large and small, are a huge red flag. Typically that is one of the first actions that is logged and traced (alongside onboarding/login), and the metrics are actively monitored. Returning 200 for failure and not catching that error is very bad API design.

    Similarly, putting engineers in a situation where debugging requires accessing unknown amounts of live sensitive customer data is generally considered bad practice (even if it happens often IRL) -- in a hurry to debug, it's easy to miss that a property should have been redacted; by then it's too late and sensitive data is exposed. Plus, in most systems with significant usage the volume of trace data is prohibitive to individually examine and search through. That's why Rollbar etc aggregate errors and captured data to identify patterns before a human (or agent, or tool) ever takes a […]

  3. xms17189

    How do you enforce the read-only guarantee across language runtimes and probe types? Is there a policy layer that rejects expressions with side effects before instrumentation, and do you expose an audit trail showing exactly what each agent probe captured?

  4. vitorbaptistaa

    Congratulations on the launch! Looks very neat.

    For people that don't have these neat observability tools (like me), I've been using https://shellshare.net (disclaimer: I made it).

    This is a single command to share a terminal live with e2e encryption. Originally it was for teaching classes or helping colleagues, but it's also very helpful for agents. I SSH into prod and run:

    > npx shellshare exec --json -- tail /var/log/my-app.log

    This generates a URL, then I can tell any agent:

    > monitor <URL>, instructions in https://shellshare.net/llms.txt

    They can see the output live. No need to install anything in the agent's machine. Next shellshare version it will be just "monitor <URL>" and the agent's instructions will be in the URL itself.

    Nothing even near what you've guys done, but it has been helpful for me. Best of luck in your startup!

  5. Natalia724

    The in-process redaction design is the part I would want to evaluate first. Is there a way to audit which values were captured and which redaction rule matched for each probe hit?

More from this day

2026-08-05