all the rules get compiled into a single regex pattern, that lets us save on iterations.
https://i.postimg.cc/jSmRpnRX/Screenshot-from-2026-08-05-10-...
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!
If you don’t know how it broke, and you don’t know how you fixed it, what exactly is it you think you understand about your application?
How does it work? Using the NodeJs inspector API or other language equivalent to drop breakpoints? Those APIs are unavailable in many serverless environments and are challenging to use alongside bundlers.
what we wanted to convey is that sometimes people confuse "the symptom went away" with "the root cause was fixed"
I have seen that a rollback, a quick redeploy, or a temporary drop in tenant load makes the alerts go away and issue is considered resolved. specially true for larger teams with many engineers and services
a real example: a dev got OOMed after a release that coincided with a flash sale. he increased memory limits, and containers stopped crashing and it was "fixed". Actualy, a newly introduced internal module had a memory leak. adding RAM just hid the leak until the next traffic spike.
hyperprobe exists to capture actual in-memory runtime state during live traffic so you can prove the root cause before changing code or scaling infra in this case
It could work, the technology isnt the limitation.
But we were clear from day one that we cant let our sdks change the memory. Even if it helped solve a real problem.. say for example resetting a bad env variable or a feature flag without redeployment.
I might be biased from my experience, but i would prefer having a bug in my system for longer that i can reliably reason with than having it solved dynamically within the app which adds another thing to keep in my mind.
for me, bug -> fails -> good bug + dynamic patch -> works -> bad
also we dont think that we ourselves wont have any downtime ever, so we design for it. we'd not want to become as critical for your app as say your database.
As of now, your app works even if our servers are down/blocked/slow, adding the ability to change memory on the fly could change this
You're correct, serverless is a bit tricky. CPU gets suspended the moment your function returns. The way it works is that you wrap your functions with a wrapper in our sdk.
that wrapper is supposed to track if there's telemetry to be sent, if so.. it sends it, otherwise, return as usual
this makes sure that when there's no active probe, there's no latency added. But when there's an active probe.. ~100-200ms could be added in the worst case if the probe is just before the return.
again, this isnt a problem in non serverless worloads because the CPU is always on.
but since probes are bounded by time and count, this will go away as soon as the time or count condition meets. beats adding new logs and redeploying in my opinion
But when the pipeline fails (bugs happen that's fine) re-running the exact same process may not be the solution.
Where does the additional intelligence that wasn't there before come from? We ran the pipeline that got it to prod on the same exact models you have access to. So the value prop is that you read the logs automatically instead of a developer directing a debug session?
You're correct inpector API is not available in many non-v8 targets. Bun also has somewhat of a partial support for inpector API but at least has a programmable debugger interface. It's not going to be as fast as native inspector but its better than nothing i guess :P
for python sys.monitoring. for JVM, we do bytecode manipulation itself.
bundlers are not an issue because we support sourcemaps. We just need mappings, not code in the sourcemaps and we do sourcemap resolutions out of process so that your app doesnt spend ~200 MB of memory for parsing sourcemaps
your coding agent will have access to your code and can see what logs you have enabled, if indeed that would help in debugging, going that route helps. it can take your agents a bunch of retries but it might get there if the answer is in logs
what we provide your coding agent is a detailed snapshot of all your variables at any line it feels would help debugging. and not just in the current call frame.. even the variables of the callers of your current function, like a debugger.
suupose funcA() -> funcB() -> funcC() -> yourCurrentFn()
we'll provide all the variables that were set in all 4 functions to your agent. debugging using this would be a lot more accurate and you just one snapshot like this instead of looking at a thousand log lines to understand why something is not working the way you want to.
this kind of data is missing from your logs and and even your traces because it will be impractical for privacy and performance.
How does the probe function technically. Inspector API I believe is unavailable on CloudFlare etc.
I once wrote something like this which could work on serverless platforms without the Inspector API. It used Typescript AST transforms to insert no-op listeners at every line, so they would dynamically eval or dump breakpoint style if a listenToLine parameter equalled their line, otherwise no-op. So trivial but not technically zero runtime cost.
makes no difference if its cold or warm start. (The latency because of us, not latency in general)
Using AST, that's clever actually! I thought along somewhat similar lines. User tree-sitter. But it needs a build step! not sure how people feel about that :D It changes your source code itself so we'd need a 2 tiered source resolution. Dirty, but doable.
And instead of having this at every line, i did this at "lines of interest" before and after every scope ends.
so at the start/end of an if condition, start/end of fn definiton. it sort of worked, but it slowed down our synthetic benchmarks for "no effect when probes arent there" by more than what i wanted to tolerate and it depended of eval which i thought devs wont accept. and using node-vm slowed it further
But will give another try again. thanks for sharing this!
If you are transforming anyway you're looking at virtually zero dev time cost and runtime cost when no probe is active of less than 1 ms.
This approach survives any environment I know of and has almost zero runtime cost.
Y
Backed by Y Combinator · AI ON-CALL AGENT
02:47 AM · order-service · 847 failures / 10 min · @priya paged
TRIGGERED
Every hour they spend in a war room is an hour they're not building. HyperProbe works the incident for them, alert to confirmed root cause before they've opened their laptop.
Node.js · TypeScript · Java · Python · Works with Cursor, Claude Code, Codex, Opencode
01
Incidents don't just break production. They break your roadmap. Your best engineers become your on-call team, every hour spent debugging is an hour not building.
02
The hotfix was an educated guess. Nobody confirmed what actually caused it. If the same conditions appear next week, the same incident fires.
03
The incident costs the same every minute it stays open. The fix takes mins. Finding takes hours, because the value that explains failure is never logged.
The solution
HyperProbe makes your coding agents drop a read-only probe on the exact line where the problem happened in prod. It captures data your logs do not have, without redeployment or restarting the service.
Every other tool reasons hard over data you already have. HyperProbe captures exact evidence.
3 to 4 hrs→<10 minTime to root cause
3 to 4→0Redeployments per incident
2 to 3→0Senior engineers on the investigation
"Sync issues used to take us days to reproduce locally. HyperProbe caught the silent data mismatch in production on the first attempt."
"During peak traffic, our listing service was black-boxing failures. HyperProbe let us inspect the live memory state during the spike. We fixed the race condition in the same hour."
Bhagwan Bansal
SDE, Housing.com
How it works
01
Alert
Picks up the page from PagerDuty, Datadog, or Slack automatically.
02
Plan
Reads logs and traces, to automatically locate the file, line with the issue, and plan debugging flow.
03
Probe
Logs not enough? Places a read-only virtual breakpoint on the suspect line. No redeploy.
04
Capture
Breakpoint fires on live traffic. Exact variable state captured at that line.
05
Confirm
Diagnosis verified against real evidence. Confirmed RCA delivered.
What is a probe?
A probe is a read-only, non-blocking snapshot of the live variable state at a specific line in your running service. It fires on real traffic, captures the exact values at that moment, and disappears after capture. Your service never pauses. Zero user impact.
The agent captures state. It cannot write memory or execute code. Every probe is logged in an immutable audit trail. Approval-gated until you trust it.
Self-hosted or private VPC. Nothing leaves your environment. PII redacted at the agent before capture. Your security team defines what can be observed.
The breakpoint fires asynchronously. Requests complete at full speed. Users experience nothing. Less than 1% overhead at 3,000 RPS.
What we cover
No exception. No alert. HyperProbe shines even with problems hardest to find.
Returns 200 with the wrong body. The trace is green. The value was never logged.
Stack trace names line 82. The cause is at line 18, or in a different file.
Exception caught and swallowed. No alert. No error. The business metric just moves.
Needs thread state at the exact moment of overlap. Nothing logs that.
Vendor added a new field or status value. Your parser has no case for it.
Payments failing, orders dropping. No exception anywhere in the stack.
Shipping this month: Memory leak diagnosis · OOM root cause · CPU spike isolation · Latency spike tracing
One real incident, start to finish
Not a feature walkthrough. This is exactly what happens when HyperProbe works an incident on your behalf.
02:47 AMAlert fires
PagerDuty fires. GET /api/orders/{id}/status is returning 500 for nearly a quarter of requests. 847 failures in the last 10 minutes. No exception in the logs.
PagerDuty alertHIGH ERROR RATE · order-service
GET /api/orders/{id}/status · 500 · 23% error rate
847 failures / 10 min · threshold exceeded
02:48 AMScouting
HyperProbe reads the distributed traces and follows the failure chain. Order service is healthy. Payment service downstream is returning 404. Payments exist in the payment gateway but are not in the system.
Trace for failing requestGET /api/orders/{id}/status 500
|
└── GET payment-service/api/getPaymentsByOrder/{orderId} 404
Payments exist in the payment gateway. Not found in the system. A write failed silently somewhere upstream.
02:49 AMProbe placed
HyperProbe identifies payments are recorded when the payment gateway calls a webhook. A virtual breakpoint placed on the webhook handler at /src/api/webhooks.ts line 78. No redeploy. Service keeps running.
Probe activatedPOST /api/webhooks/payments
file: /src/api/webhooks.ts · line 78
Non-blocking · Read-only · No redeploy
02:50 AMBug found
Gateway is sending PENDING. The code has no case for it. Idempotency check marks payment as processed before confirming state. Payment never written to DB. No exception fires.
Live snapshot · webhooks.ts:78 · captured 02:50:14 UTCstatus = "PENDING" ← payment gateway sending this, no handler exists
duplicate = null ← first time seen, passes through
db.insert → never called
redis.set → called anyway, payment locked out permanently
Payment gateway started sending PENDING, a status your code never handled. Idempotency key written before state is checked. Payment marked processed, never recorded.
02:52 AMFix suggested
Payment gateway started sending PENDING, a status your code never handled. Idempotency key written before state is checked. Payment marked processed, never recorded.
Before and after
Your best engineers should not be your on-call team. HyperProbe handles the investigation so they can go back to building.
Without HyperProbe
02:47 AM
Alert fires. Engineer paged.
02:50 AM
Stack trace points to line 82. The variable that caused it was set several frames up, in a different file. No log captures it there.
03:10 AM
Frame located. Variable value not visible. Adds a log line to capture it.
03:40 AM
CI/CD deploys. 30 minutes gone. Waiting for the condition to reproduce in production.
04:15 AM
First log visible. Partial data. Not enough. Another log line. Another 30-minute deploy cycle.
05:20 AM
After 2 to 3 redeploy cycles, root cause confirmed. 2 hours 33 minutes.
With HyperProbe
02:47 AM
Alert fires. HyperProbe picks it up.
02:48 AM
HyperProbe uses your coding agent to locate the exact frame where the probe should go. All in background.
02:49 AM
HyperProbe activates a virtual breakpoint at that exact line. No redeploy.
02:53 AM
Breakpoint fires safely at next request. Exact variable value captured. Service keeps running.
02:56 AM
Root cause confirmed. 9 minutes from alert to evidence-backed diagnosis.
03:00 AM
Engineer commits the fix.
Pricing
Probes and captures are unlimited on every plan. You should never hit a wall in the middle of an incident.
Free
$0 forever
1 service · managed cloud
Install the SDK and see a real capture the same afternoon.
Most teams
Professional
$99 per service per month
$79 billed annually · 3 service minimum
For teams running real production traffic who want the whole stack instrumented, not one service.
Enterprise
Custom
Annual contract · volume pricing
For teams whose security review has to sign off before anything touches production.
First incident we work with you is free · Cancel any month · No seat counts · No host counts · No capture limits
See full pricing and what is in each plan →
This is built for you if
If you don't, we're probably not the right fit yet. If you do, let's talk.
If you have a specific memory of that night, HyperProbe is built for you. The data you needed was never in the logs. You grepped, guessed, redeployed, and hoped. It does not have to work that way.
When prod breaks, your most expensive hire gets paged to do work a machine should do. Every night on-call is a night they resent. And your best people have options.
Without the exact variable state at the moment of failure, every fix is a guess. Guesses hold until they don't. HyperProbe confirms root cause so the fix is final, not deferred.
Start the POC
30 minutes. Your service. Your incident. You'll see a confirmed root cause before the call ends — or there's nothing more to discuss.
Node.js · TypeScript · Java · Kotlin · Runs in your own infra · Up in 15 minutes
