sixty

performance-monitoring, das bei der änderung beginnt

Erkenne, welches Deployment deine App beschädigt hat.

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.

Sixtyacme / storefrontrelease v2.4.0
orders.enrichOrdersNew finding
Detected 3 min after deploy
N+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 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

Ein Fund, mit dem dein Agent arbeiten kann.

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

neuer fund9d3f01e
N+1

orders.enrichOrders

vorher1Abfrage pro Anfrage→nach diesem deployment14Abfragen pro Anfrage
Begann mit
v2.4.0
Wahrscheinliche Änderung
#815 Bestellabfrage erweitern
Läuft in
orders/getUserOrders.ts:47
SixtyAn deinen Coding-Agenten übergeben →

Regressionserkennung für KI-Laufzeiten

Erkenne, wenn ein Agent langsamer, teurer oder in einer Tool-Schleife gefangen wird.

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.

AI cost regressionrelease e18c6ba

Der Support-Agent kostet 3,5× mehr pro erfolgreichem Lauf

vorher $0,0164→$0,0426 nach diesem Deploy
POST /api/support1,930 → 4,630 tokens · 3 → 7 toolssupport-agent →

ein Trace durch die ganze Anwendung

Browser, Backend, Modell, Tools und Datenbank bleiben verbunden.

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.

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
Cost/request +160% · tool calls 3 → 7 · release e18c6ba

Session Replay als Teil der Beweise

Sieh, was der Nutzer sah, als sich die Zahlen änderten.

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.

/checkout
Something went wrong
↖
00:11dead click00:18 browser error

ein stiller kreislauf

Du lieferst aus. Wir finden es. Dein Agent behebt es.

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.

  1. Du veröffentlichst eine Änderung

    Die Release-Markierung kommt von der Plattform, auf der du bereits deployest.

  2. Sixty erkennt die Strukturänderung

    Aus einer Abfrage wurden vierzehn. Niemand musste vorher einen Grenzwert erfinden.

  3. Dein Agent erhält die Belege

    Messwerte, Abfrage, Stackframes und der relevante Diff kommen gemeinsam an.

Dann veröffentlichst du erneut — und dieses Release wird zur Grundlinie, an der das nächste gemessen wird.

vom release bis zur codezeile

Nicht nur welches Deployment. Welcher Pull Request.

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

  • #812Abhängigkeiten anheben
  • #814Rechnungsexport hinzufügen
  • #815Die Bestellabfrage aufweitenorders/getUserOrders.ts
  • #818Textkorrekturen auf der Einstellungsseite
  1. Fünf Releases hintereinander, und orders.getUserOrders gibt jedes Mal dreißig Zeilen zurück. Das ist die Grundlinie. Niemand hat sie gesetzt.
  2. Dann gibt es dreißigtausend zurück. Nichts flog, nichts lief in einen Timeout, und auf einer warmen Datenbank fühlte sich die Seite weiterhin gut an.
  3. Es begann bei v2.4.0. So weit kann es dir jedes Monitoring-Werkzeug am Markt sagen — und in diesem Deployment kamen vier Änderungen heraus.
  4. Es war #815, das die Datei berührt hat, in der die Abfrage läuft. Das ist der Satz, auf den dein Coding-Agent handeln kann, und der, den dir sonst nichts gibt.
Die Achse ist über dem letzten Balken gebrochen — das Tausendfache passt nicht auf ein Diagramm dieser Größe. Die Zeilen und die Operation sind das, was pnpm e2e auf einem Klon des Repositories ausgibt; die Release-Tags und Pull-Request-Nummern sind illustrativ.
Was es liest, und was es nie speichert →

dauerhaft bedeutet wirklich dauerhaft

Der Punkt ist, dass es nie aufhört.

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.

beobachtetcheckout-api · production
  1. 4c02f1akeine Abweichung · 47 Operationen verglichen2 min
  2. bb7e340keine Abweichung · 47 Operationen verglichen3 min
  3. 2e9b503gibt nichts zurückprofile.load12 Zeilen → 0 Zeilen4 min
  4. 5a1d0c8keine Abweichung · 48 Operationen verglichen2 min
  5. c40aa19keine Abweichung · 48 Operationen verglichen2 min
  6. 9d3f01eZeilenorders.getUserOrders30 Zeilen → 30.000 Zeilen4 min
  7. 9d3f01eN+1orders.enrichOrders1 Abfrage → 14 Abfragen4 min
  8. 7b21ee4keine Abweichung · 46 Operationen verglichen3 min
  9. a3f9c21keine Abweichung · 46 Operationen verglichen2 min
  10. d81b904keine Abweichung · 46 Operationen verglichen2 min
Sieben dieser zehn Deployments haben nichts verändert, was die normale Woche ist und der Grund, warum das nichts ist, woran du selbst denkst: Prüfe nach jedem Release, und die Antwort lautet sechsmal hintereinander „in Ordnung“ — bis sie es nicht mehr ist. Rekonstruiert aus einem pnpm e2e-Lauf — das sind seine Zahlen — mit illustrativen Revisionen.

kein neuer arbeitsablauf

Funktioniert mit dem, was du sowieso offen hast.

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.

Claude Code

Ein Befehl. Die Befunde kommen als Payload an, mit der er arbeiten kann.

Cursor

Dieselben zwei Werte als Konfigurationsblock.

Lovable

Kein eigener Editor — füge einen Prompt in seinen Chat ein.

Replit

Agent und Deployments an einem Ort; der Release-Marker kommt gratis dazu.

VS Code

Copilot, Continue, oder was du sonst eingebunden hast.

Codex

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

Mit deinem Agenten installieren. Zweimal veröffentlichen.

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.

ein befehl verbindet den agentenclaude 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 starten
Solo€14.99/Monat1 App
Studio€49.99/Monat5 Apps
Alle Preise ansehen →

das nächste deployment ist das nützliche

Finde heraus, was deine letzte Änderung angerichtet hat.

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.

Sixty — finde heraus, welches Deployment deine Anwendung kaputt gemacht hat