Deine App hat keinen Server. Fehler hat sie trotzdem.

Was es misst

Jede Supabase-Abfrage, die die Seite macht

Wie viele pro Interaktion laufen, wie viele Zeilen jede zurückgibt, wie groß die Antwort ist und wie lange sie gedauert hat. Hier sitzt „es ist langsam geworden“ fast immer.

Wie schnell die Seite ist, pro Route

LCP, INP, CLS und TTFB am echten p75 über alle, die sie geladen haben — kein Laborwert von einer Maschine. Nach Land aufgeschlüsselt, weil eine Seite, die bei dir in Ordnung ist, dort, wo die Latenz schlechter ist, unbenutzbar sein kann.

Worauf Leute geklickt haben, und ob es funktioniert hat

Klicks, die nichts getan haben, wiederholtes Klicken auf dasselbe Element, und Interaktionen, die die Seite hunderte Male neu zeichnen.

Auth, Storage, Edge Functions und Realtime

Eine Supabase-App besteht aus vier Diensten, nicht aus einem, und der Agent versteht, was jeder Endpunkt tut, statt nur, was er gekostet hat — eine abgelehnte Anmeldung, eine fehlende Spalte, ein zurückgewiesener Schreibvorgang und ein Kanal, der sich nicht abonnieren konnte, kommen also jeweils als das an, was sie sind, statt als anonyme fehlgeschlagene Anfrage.

Der Code, bevor er läuft

Ein Button ohne Handler, ein Effekt, dessen Abhängigkeiten garantieren, dass er ewig läuft, ein Abonnement, das nie abgebaut wird. Diese senden zur Laufzeit nichts — ein Handler, der nie angehängt wurde, kann nicht gemessen werden —, also werden sie zur Build-Zeit aus dem Quellcode gelesen und danach sortiert, wie viel Verkehr die Datei tatsächlich bedient.

Was es findet

Jedes davon wird gegen das Release davor verglichen, der Befund benennt also die Änderung und nicht den Tag.

Was in deinem Verlauf landet

Kein Dashboard zum Lesen. Eine Karte pro Befund, mit den Zahlen, dem Release, das sie verändert hat, und den Belegen, die dein Coding-Agent braucht, um die Lösung zu schreiben.

Wie es installiert wird

Das installierst du nicht von Hand. Füge einen Prompt in den Chat von Lovable ein, und er verdrahtet den Agenten — ein Vite-Plugin, ein init-Aufruf und eine Route, die Telemetrie weiterleitet, damit nie ein Schlüssel in deinem Bundle landet. Wenn du dich anmeldest, wird dieser Prompt mit deinem Schlüssel darin für dich geschrieben.

npm install @sixty-sh/supabase

// vite.config.ts
import drift from '@sixty-sh/supabase/vite'
export default defineConfig({ plugins: [react(), drift()] })

// src/integrations/supabase/client.ts — the file every Lovable app has
import { withSixty } from '@sixty-sh/supabase'

export const supabase = withSixty(createClient(URL, ANON_KEY), {
  key: 'sixty_pk_…',
  service: 'my-app',
  endpoint: 'https://ingest.sixty.sh',
})

Dann veröffentliche zweimal. Der Vergleich ist an Veröffentlichungen verankert und nicht an die Uhr, der erste Befund kommt also nach deiner nächsten — es gibt nichts, womit man eine einzelne Version vergleichen könnte.

Was es nicht tut

• Befunde aus einem veröffentlichten Build zeigen auf die Abfrage und die Route, nicht auf eine Zeile deines Quellcodes. Produktions-Bundles sind minifiziert, und die Sourcemap, die das rückgängig machen würde, wird noch nicht gelesen — du bekommst also „diese Abfrage auf dieser Seite“ statt „diese Datei, Zeile 40“.
• Der Lovable-Preview reicht nicht. Er läuft auf einem Dev-Server ohne fingerabdruckbehaftete Assets, es gibt also keine Version, an der ein Vergleich verankert werden könnte — der Vergleich braucht zwei echte Veröffentlichungen.
• Hier wird kein Server beobachtet, weil du keinen hast. Wenn du später eigene Edge Functions hinzufügst, brauchen die den Node-Agenten, um sichtbar zu sein.

Falls du wegen einer dieser Sachen hier bist