9d3f01eorders.enrichOrders
- Begann mit
v2.4.0- Wahrscheinliche Änderung
- #815 Bestellabfrage erweitern
- Läuft in
orders/getUserOrders.ts:47
performance-monitoring, das bei der änderung beginnt
Sixty erkennt, wenn ein Release das Verhalten deiner App verändert — aus einer Abfrage werden vierzehn, aus dreißig Zeilen dreißigtausend — und übergibt die Belege an den Coding-Agenten, den du bereits geöffnet hast.
This release changed what this operation normally does.
1 Befehl zur Installation0 Dashboards zu bauen0 Schwellwerte einzustellen0 Nutzerdaten erhoben
Zahlst du schon für etwas anderes?Wie sich das zu Datadog, New Relic und Sentry verhält →die antwort statt noch eines dashboards
Der Wert änderte sich mit einem Release. Ein Pull Request berührte den ausgeführten Code. Abfrage, Stackframes und Deployment-Diff werden mitgeliefert.
Der Kreislauf im Ganzen, und wie dein Agent ihn schließt →die antwort statt noch eines dashboards
9d3f01ev2.4.0orders/getUserOrders.ts:47Regressionserkennung für KI-Laufzeiten
Sixty vergleicht dieselbe Agentenaufgabe über Releases hinweg: Tokens, Modellkosten, Zeit bis zum ersten Token, Tool-Aufrufe und Fehler. Der Feed meldet die Änderung; ein bereinigter Trace zeigt die Ursache.
release e18c6baein Trace durch die ganze Anwendung
Der Trace-Kontext folgt der Anfrage über Dienste hinweg. Eine Modellgenerierung besitzt ihre Tool-Aufrufe; ein Tool besitzt seine HTTP- und Datenbankarbeit. So nennt Sixty die genaue Ursache und den Pull Request.
Session Replay als Teil der Beweise
Bei Browserfehlern, toten Interaktionen oder hängenden Ladevorgängen speichert Sixty eine kurze maskierte Aufnahme rund um den Fehler. Replay ist ein Beweis am Fund, kein Archiv aller Besucher.
ein stiller kreislauf
Es gibt kein Dashboard zu kontrollieren und keinen Alarm zu konfigurieren. Die drei Dinge unten sind das ganze Produkt, und nur das erste davon machst du selbst.
Die Release-Markierung kommt von der Plattform, auf der du bereits deployest.
Aus einer Abfrage wurden vierzehn. Niemand musste vorher einen Grenzwert erfinden.
Messwerte, Abfrage, Stackframes und der relevante Diff kommen gemeinsam an.
vom release bis zur codezeile
Ein Deployment enthält viele Änderungen. Sixty verwendet die exakten Commits zwischen den Releases und nennt dann den Pull Request, der die Datei hinter dem Fund verändert hat.
v2.4.04 Änderungen kamen damit heraus
orders.getUserOrders gibt jedes Mal dreißig Zeilen zurück. Das ist die Grundlinie. Niemand hat sie gesetzt.pnpm e2e auf einem Klon des Repositories ausgibt; die Release-Tags und Pull-Request-Nummern sind illustrativ.dauerhaft bedeutet wirklich dauerhaft
Jedes Release wird mit dem vorherigen verglichen, ein paar Minuten nachdem es draußen ist, solange die Anwendung läuft. Du startest nichts, du wirst nichts gefragt, und es gibt keinen Durchlauf, an den du denken musst.
4c02f1akeine Abweichung · 47 Operationen verglichen2 minbb7e340keine Abweichung · 47 Operationen verglichen3 min2e9b503gibt nichts zurückprofile.load12 Zeilen → 0 Zeilen4 min5a1d0c8keine Abweichung · 48 Operationen verglichen2 minc40aa19keine Abweichung · 48 Operationen verglichen2 min9d3f01eZeilenorders.getUserOrders30 Zeilen → 30.000 Zeilen4 min9d3f01eN+1orders.enrichOrders1 Abfrage → 14 Abfragen4 min7b21ee4keine Abweichung · 46 Operationen verglichen3 mina3f9c21keine Abweichung · 46 Operationen verglichen2 mind81b904keine Abweichung · 46 Operationen verglichen2 minpnpm e2e-Lauf — das sind seine Zahlen — mit illustrativen Revisionen.kein neuer arbeitsablauf
Sixty übernimmt das Beobachten; der Coding-Agent, den du ohnehin benutzt, übernimmt das Beheben. Die Übergabe dazwischen ist ein MCP-Server — deshalb ist die Installation überall dieselben zwei Werte, und deshalb wird sie dort, wo du keinen eigenen Editor hast, zu einem Prompt, den du in einen Chat einfügst.
Ein Befehl. Die Befunde kommen als Payload an, mit der er arbeiten kann.
Dieselben zwei Werte als Konfigurationsblock.
Kein eigener Editor — füge einen Prompt in seinen Chat ein.
Agent und Deployments an einem Ort; der Release-Marker kommt gratis dazu.
Copilot, Continue, oder was du sonst eingebunden hast.
Und Windsurf, Zed, Cline — alles, was MCP spricht.
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 → Alle Sprachen und Frameworks, in denen es läuft →kleine verpflichtung, vollständiges produkt
Beide Tarife enthalten alle Funde, die Agent-API und MCP. Dein 7-Tage-Test beginnt mit dem vollständigen Produkt; der erste Vergleich kommt nach dem nächsten Release.
claude mcp add sixty …Dieser letzte Schritt ist der ehrliche Haken. Die Installation dauert eine Minute; der erste Vergleich dauert so lange wie dein nächstes Deployment, weil es nichts gibt, womit man ein einzelnes Release vergleichen könnte.
7-Tage-Test startendas nächste deployment ist das nützliche
Lass Sixty beobachten, was sich ändert, und den Agenten, der deinen Code kennt, die Ursache beheben.
Keine Benutzer-IDs, Prompt-Texte, Modellantworten oder Abfragewerte. Routen, Tool-Eingaben und Ergebnisse werden auf ihre Struktur reduziert; Replay-Text ist standardmäßig maskiert.
Rekonstruiert aus der Ausgabe von pnpm e2e, das genau diese Regression sät und erkennt. Die Zahlen sind die dieses Laufs.
Alles ruhig. Keine Abweichung seit deinem letzten Deployment.
30 Zeilen → 30.000 Zeilen1000×
Die Abfrage hat ihre where-Klausel verloren, liest also die ganze Tabelle, und der Code filtert danach. Auf deinem Laptop wurde nichts langsamer — die Tabelle dort hat vierzig Zeilen.
Wartet auf jemanden. Sie ist seit vier Sekunden offen.Von deinem Agenten übernommen — Belege über MCP geholt: die Abfrage, die Stack-Frames, die Zahlen.Gelöst · „die fehlende where-Klausel auf user_id ergänzt“