9d3f01eN+1
orders.enrichOrders
before1query per request→after this deploy14queries per request
- Started at
v2.4.0- Likely change
- #815 Widen the orders query
- Runs in
orders/getUserOrders.ts:47
performance monitoring that starts with the change
Know which deploy broke your app.
Sixty notices when a release changes how your app behaves — one query becomes fourteen, thirty rows become thirty thousand — and hands the evidence to the coding agent you already have open.
orders.enrichOrdersNew finding
Detected 3 min after deployN+1 query
orders.enrichOrders
This release changed what this operation normally does.
Previous release1 query
→Current release14 queries
- Started at
- v2.4.0
- Code location
- orders/getUserOrders.ts:47
Ask Sixty about this finding…⌘ K
1 command to install0 dashboards to build0 thresholds to tune0 user data collected
Already paying for something else?How this compares to Datadog, New Relic and Sentry →the answer, not another dashboard
A finding your agent can act on.
The count changed at one release. One pull request touched the code it runs in. The query, stack frames and deployment diff travel with it.
The loop in full, and how your agent closes it →the answer, not another dashboard
AI runtime regression detection
See which release made every AI request cost more.
Sixty separates increased traffic from increased cost per request, then names the endpoint, agent, model and repeated tool calls responsible for the change.
release e18c6baPOST /api/support costs 160% more per request
$0.0164 before→$0.0426 after this deploy
one trace, across the whole application
From the endpoint to the repeated tool call.
Trace context connects the browser, endpoint, agent, model, MCP tools and database. The trace is evidence for the finding: support got expensive because tool calls rose from three to seven.
browserSupport form submitted0ms
requestPOST /api/support4.82s
generationsupport-agent · gpt-5-mini4.20s
toolMCP · knowledge-base.search ×4310ms
databaseSELECT help_articles · 8 rows96ms
toolMCP · orders.lookup ×2424ms
session replay, attached to the evidence
Replay the failed request.
When a browser error, dead interaction or stuck load produces a finding, Sixty keeps a short masked recording around the failure. Replay is evidence on the finding—not a library of every person who visited.
/checkout
Something went wrong
↖
one quiet loop
You ship it. We catch it. Your agent fixes it.
There is no dashboard to check and no alert to configure. The three things below are the entire product, and you only do the first one.
You ship a change
The release marker comes from the platform you already deploy with.
Sixty sees the shape change
One query became fourteen. Nobody had to invent a threshold first.
Your agent gets the evidence
Measurements, query, stack frames and the relevant diff arrive together.
from release to line of code
Not just which deploy. Which pull request.
A deploy contains many changes. Sixty uses the exact commits between releases, then names the pull request that touched the file behind the finding.
v2.4.04 changes shipped in it
- #812Bump dependencies
- #814Add invoice export
- #815Widen the orders queryorders/getUserOrders.ts
- #818Copy fixes on the settings page
- Five releases in a row, and
orders.getUserOrdershands back thirty rows every time. That is the baseline. Nobody set it. - Then it returns thirty thousand. Nothing threw, nothing timed out, and on a warm database the page still felt fine.
- It started at v2.4.0. Every monitoring tool on the market can tell you this much — and four changes shipped in that deploy.
- It was #815, which touched the file the query runs in. That is the sentence your coding agent can act on, and it is the one nothing else hands you.
pnpm e2e prints on a clone of the repository; the release tags and pull request numbers are illustrative.always on means always on
The point is that it never stops.
Every release gets compared to the one before it, a couple of minutes after it goes out, for as long as the app is running. You do not start it, you are not asked anything, and there is no run to remember to do.
watchingcheckout-api · production
4c02f1ano drift · 47 operations compared2 minbb7e340no drift · 47 operations compared3 min2e9b503returns nothingprofile.load12 rows → 0 rows4 min5a1d0c8no drift · 48 operations compared2 minc40aa19no drift · 48 operations compared2 min9d3f01erowsorders.getUserOrders30 rows → 30,000 rows4 min9d3f01eN+1orders.enrichOrders1 query → 14 queries4 min7b21ee4no drift · 46 operations compared3 mina3f9c21no drift · 46 operations compared2 mind81b904no drift · 46 operations compared2 min
pnpm e2e run — those are its numbers — with illustrative revisions.no new workflow
Works with whatever you already have open.
Sixty does the watching; the coding agent you already use does the fixing. The handover between them is one MCP server, which is why the install is the same two values everywhere — and why building somewhere with no editor of your own is a prompt pasted into a chat instead.
Claude Code
One command. The findings arrive as a payload it can act on.
Cursor
The same two values as a config block.
Lovable
No editor of your own — paste one prompt into its chat.
Replit
Agent and deploys in one place; the release marker comes free.
VS Code
Copilot, Continue, or whatever else you have wired in.
Codex
And Windsurf, Zed, Cline — anything that speaks MCP.
OpenTelemetry / OTLP · Node · Python · Go · Ruby · PHP · Browser · React Native · Supabase
Keep Grafana, Prometheus, Elastic, Vercel, AWS, or the backend you already use. Send the same OTEL traces and metrics to Sixty for release-aware problem detection.
OpenTelemetry setup → Every language and framework it runs in →small commitment, complete product
Install with your agent. Publish twice.
Both plans include every finding, the agent API and MCP. Your 7-day trial starts with the full product; the first comparison arrives after the next release.
one command connects the agent
claude mcp add sixty …That last step is the honest catch. Install takes a minute; the first comparison takes as long as your next deploy, because there is nothing to compare a single release against.
Start the 7-day trialthe next deploy is the useful one
Find out what your last change did.
Let Sixty watch what changes, then let the agent that knows your code fix it.
No user IDs, prompt text, model responses or query values. Routes, tool inputs and results are reduced to their shape before they leave your app; replay text is masked by default.
Watch it catch one
CloseReconstructed from the output of pnpm e2e, which seeds this exact regression and detects it. The numbers are that run’s.
deploy 9d3f01deploy 4c02f1a
All quiet. No drift since your last deploy.
highrowsorders.getUserOrdersopenclaimedresolved
30 rows → 30,000 rows1000×
The query lost its where clause, so it reads the whole table and the code filters afterwards. Nothing got slower on your laptop — the table there has forty rows in it.
Waiting for somebody. It has been open for four seconds.Claimed by your agent — evidence pulled over MCP: the query, the stack frames, the numbers.Resolved · “added the missing where clause on user_id”
- You deploy
- We compare it to the last one
- Your agent takes it
- It closes itself