failproofai 1.0.1-beta.1 → 1.0.1

package/.next/standalone/docs-old/de/agenteye/cli.mdx

@@ -0,0 +1,350 @@
+---
+title: "CLI"
+description: "Steuere die gesamte Failproof AI Observability vom Terminal oder einem Skript aus: kein Umweg über das Dashboard."
+---
+
+
+Steuere die gesamte Failproof AI Observability vom Terminal oder einem Skript aus: kein Umweg über das Dashboard. Die `agenteye` CLI fragt deine Daten ab (Sessions, Event-Logs, Evaluierungen) und verwaltet deine Organisation (API-Keys, Nutzer, Einstellungen, Alerts, Incidents, gespeicherte Abfragen) – greife darauf zurück, wenn du eine Prüfung automatisieren, Observability in CI einbinden oder einen Coding-Agenten die Produktion inspizieren lassen möchtest. Jeder Befehl unterstützt ein `--json`-Flag, sodass er gleichermaßen für dich an der Eingabeaufforderung oder für einen Coding-Agenten (Claude Code, Cursor) funktioniert, der das Ergebnis parst.
+
+Mit einer einzigen Binary kannst du:
+
+- **Deine Daten lesen**: `sessions`, `events`, `evals`, `errors` (gefiltert nach Zeit, Agent, Umgebung, Score).
+- **Deine Organisation verwalten**: `keys`, `users`, `settings`, `alerts`, `incidents`.
+- **Analysen ausführen**: gespeichertes SQL und einen Ad-hoc-Query-Runner (`query`).
+- **Den KI-Assistenten befragen**: denselben schreibgeschützten Analysten, mit dem du im Dashboard chattest (`agent`).
+
+> **Hinweis:** Dies ist die `agenteye` CLI, ein anderes Werkzeug als der Collector-Daemon (`agenteye-collector`). Die CLI kommuniziert mit deinem Dashboard; der Collector sendet Events an den Server.
+
+---
+
+## Schnellstart
+
+Von null zum ersten Ergebnis in vier Zeilen. Weise die CLI auf dein Dashboard, melde dich an, bestätige deine Identität und rufe dann die letzten 24 Stunden an Runs ab:
+
+```bash
+pipx install agenteye
+agenteye --base-url https://agenteye.example.com login --email you@example.com   # emailed 6-digit code
+agenteye whoami                                                                  # confirm user + active org
+agenteye --json sessions --since 24h                                             # one row per agent run, last 24h
+```
+
+Der letzte Befehl gibt ein JSON-Objekt mit den neuesten Sessions aus (neueste zuerst, standardmäßig auf 50 begrenzt). Leite es in `jq` weiter, um es zu filtern, oder lass `--json` weg für eine umrahmte, kolorierte Tabelle. Jede Zeile enthält den Status des Runs und, sofern ein Evaluator ihn bewertet hat, seine Metrik-Scores (hier gekürzt):
+
+```json
+{
+  "sessions": [
+    {
+      "session_id": "run-8f2a",
+      "agent_id": "checkout-bot",
+      "environment": "prod",
+      "status": "error",
+      "scores": { "helpfulness": 0.42, "tool_efficiency": 0.55 },
+      "event_count": 37,
+      "started_at": "2026-07-16T09:14:02Z",
+      "last_event_at": "2026-07-16T09:14:48Z"
+    }
+  ],
+  "next_cursor": null
+}
+```
+
+Der Rest dieser Seite erläutert die einzelnen Bestandteile: [Installation](#installation) in einer isolierten Umgebung, [Anmeldung](#authentication), [Konfiguration](#configuration), die [globalen Konventionen](#global-options--conventions), die alle Befehle teilen, sowie die [vollständige Befehlsreferenz](#command-reference).
+
+---
+
+## Installation
+
+Die CLI ist ein öffentliches PyPI-Paket namens **`agenteye`**. Installiere es in einer isolierten Umgebung, damit es stets eigene Abhängigkeiten hat:
+
+```bash
+pipx install agenteye
+# or
+uv tool install agenteye
+```
+
+Python 3.10+ ist erforderlich. Der installierte Befehl lautet **`agenteye`**:
+
+```bash
+agenteye --version
+agenteye --help
+```
+
+> **Hinweis:** Das Failproof AI Observability Python SDK verwendet ebenfalls den Distributionsnamen `agenteye`. Die Installation der CLI mit `pipx` oder `uv tool` (statt `pip install` in ein gemeinsames Virtualenv) verhindert Konflikte zwischen beiden. Ein einfaches `pip install agenteye` ist nur dann problemlos, wenn das SDK nicht in derselben Umgebung installiert ist.
+
+---
+
+## Authentifizierung
+
+Die CLI authentifiziert sich gegenüber dem **Dashboard** mit einem per E-Mail zugesandten Einmalcode:
+
+```bash
+agenteye login --email you@example.com
+# A 6-digit code is emailed to you; paste it at the prompt.
+```
+
+Das Session-Token wird in `~/.agenteye/cli.json` gespeichert (nur für dich lesbar, Modus `0600`) und ist standardmäßig 24 Stunden gültig. Nach Ablauf führe erneut `agenteye login` aus.
+
+```bash
+agenteye whoami     # show the current user, active org, and permissions
+agenteye logout     # revoke the session and clear the stored token
+```
+
+`whoami` schlägt bei einer fehlenden oder abgelaufenen Session nie fehl; stattdessen meldet es `logged_in: false`, sodass ein Skript oder Agent den Auth-Status sicher abfragen kann (es kann dennoch mit einem Nicht-Null-Wert enden, wenn keine Basis-URL gesetzt oder das Dashboard nicht erreichbar ist).
+
+**Voraussetzungen:** Deine E-Mail-Adresse muss für die Anmeldung am Dashboard berechtigt sein (frage deinen Failproof AI Observability-Administrator), und das Dashboard muss über seine Basis-URL erreichbar sein (siehe [Konfiguration](#configuration)). Wenn du einen Code anforderst und keiner eintrifft, ist deine E-Mail-Adresse wahrscheinlich noch nicht für den Dashboard-Zugang freigeschalten.
+
+---
+
+## Organisation auswählen (Multi-Tenant)
+
+Wenn dein Konto zu mehr als einer Organisation gehört, wähle die aktive **bei der Anmeldung**; sie wird gespeichert und für alle späteren Befehle verwendet:
+
+```bash
+agenteye login --org acme           # authenticate and set the active tenant in one step
+agenteye orgs list                  # the orgs you can access (the active one is marked)
+agenteye orgs switch globex         # change the saved default
+agenteye --org globex sessions      # override for a single command
+```
+
+Wenn du genau einer Organisation angehörst, wird diese automatisch ausgewählt, und du kannst `--org` vollständig ignorieren. Wenn du mehreren angehörst und keine auswählst, listet die CLI sie auf und fordert dich auf, den Befehl mit `--org <slug>` erneut auszuführen. Die aktive Organisation wird bei jeder Anfrage an das Dashboard gesendet, und deine Berechtigungen werden **pro Organisation** aufgelöst; `agenteye whoami` zeigt die aktive Organisation, deine Berechtigungen darin und alle deine Mitgliedschaften.
+
+---
+
+## Konfiguration
+
+| Einstellung | Flag | Umgebungsvariable | Standard |
+|---|---|---|---|
+| Dashboard-Basis-URL | `--base-url` | `AGENTEYE_DASHBOARD_URL` | **erforderlich** (kein Standard) |
+| Aktive Organisation/Tenant | `--org` | `AGENTEYE_ORG` | bei Anmeldung gewählt; in `~/.agenteye/cli.json` gespeichert |
+| Session-Token | `--token` | `AGENTEYE_CLI_TOKEN` | aus `~/.agenteye/cli.json` |
+| JSON-Ausgabe | `--json` | `AGENTEYE_CLI_JSON` | deaktiviert |
+| TLS-Überprüfung überspringen | `--insecure` / `--secure` | `AGENTEYE_INSECURE` | deaktiviert (bei Anmeldung gespeichert) |
+| Anfrage-Timeout (Sekunden) | `--timeout` | _(keine)_ | 30 |
+| Nutzungstelemetrie deaktivieren | _(keine)_ | `AGENTEYE_ANALYTICS_DISABLED` (oder `DO_NOT_TRACK`) | Telemetrie ist derzeit deaktiviert; es wird nichts gesendet |
+
+Die Auflösungsreihenfolge ist **Flag → Umgebungsvariable → Konfigurationsdatei**. Es gibt keinen Standard; du musst die CLI auf dein Dashboard zeigen, entweder pro Befehl (`--base-url https://agenteye.example.com`) oder einmalig über die Umgebung (wird auch nach deinem ersten `login` gespeichert):
+
+```bash
+export AGENTEYE_DASHBOARD_URL=https://agenteye.example.com
+```
+
+Das Konfigurationsverzeichnis berücksichtigt `AGENTEYE_HOME` (dieselbe Konvention wie beim SDK und Collector); wenn gesetzt, liegt `cli.json` unter `$AGENTEYE_HOME/cli.json`.
+
+### Selbstsignierte oder interne TLS-Zertifikate
+
+Wenn dein Dashboard über HTTPS mit einem selbstsignierten oder internen Zertifikat betrieben wird (zum Beispiel ein roher Load-Balancer-Hostname), lehnt die TLS-Überprüfung es mit einem `CERTIFICATE_VERIFY_FAILED`-Fehler ab. Übergib `--insecure`, um die Zertifikatsprüfung zu überspringen:
+
+```bash
+agenteye --base-url https://agenteye.internal --insecure login
+```
+
+`--insecure` wird **bei der Anmeldung in `cli.json` gespeichert**, sodass spätere Befehle die Überprüfung automatisch überspringen; du musst das Flag nicht wiederholen. Übergib `--secure` für einen einmaligen verifizierten Aufruf oder um die Überprüfung bei deiner nächsten Anmeldung wieder zu aktivieren. Die CLI gibt vor jedem Befehl, der das Dashboard kontaktiert, eine Warnung an stderr aus, solange die Überprüfung deaktiviert ist. Das Überspringen der Überprüfung beseitigt den Schutz vor Man-in-the-Middle-Angriffen; stelle sicher, dass du dem Netzwerkpfad zu deinem Dashboard vertraust (VPN, privates Subnetz usw.), bevor du dich darauf verlässt.
+
+---
+
+## Telemetrie & Datenschutz
+
+> **Hinweis:** Die ausgelieferte CLI sendet **heute keine Nutzungstelemetrie.** Ein globaler Kill-Switch ist aktiviert, sodass unabhängig von deiner Umgebung nichts übertragen wird. Der folgende Abschnitt beschreibt die Opt-out-Möglichkeit für den Fall, dass Telemetrie jemals aktiviert wird.
+
+Selbst wenn aktiviert, wären Telemetriedaten **ausschließlich anonyme Nutzungsanalysen**, niemals deine Agenten-, Session- oder Event-Daten:
+
+- **Keine Agenten-, Session- oder Event-Daten verlassen jemals deine Infrastruktur.** Nur CLI-Nutzung würde gemeldet: der Befehls- und Unterbefehls-Name (z. B. `keys create`), die **Namen** der verwendeten Flags (niemals deren Werte), Erfolgs-/Exit-Status und Dauer, sowie ein Pro-Aktion-Event für Mutationen (z. B. `api_key_created`, `query_run`), das nur statische Namen/Enums und grobe Zählwerte enthält. Deine Dashboard-URL, dein Session-Token, deine E-Mail, dein Org-Slug, Ressourcen-IDs, SQL, Key-Secrets und Abfragefilter würden **niemals** gesendet. Operatoren würden nur durch eine opaque interne ID identifiziert, niemals per E-Mail.
+- **Vorab abmelden** durch Setzen von `AGENTEYE_ANALYTICS_DISABLED=1` in der Umgebung der CLI (die CLI berücksichtigt auch die toolübergreifende Konvention `DO_NOT_TRACK=1`). Dies greift sofort, wenn Telemetrie jemals aktiviert wird, sodass eine datenschutzbewusste Umgebung dauerhaft abgemeldet bleiben kann.
+- Wenn Telemetrie aktiviert wäre, würde die CLI direkt an PostHog senden (`https://us.i.posthog.com`); ein Gerät, bei dem dieser Host geblockt ist, würde still nichts senden, ohne dass die CLI beeinträchtigt würde.
+
+---
+
+## Globale Optionen & Konventionen
+
+Lies dies einmal; es gilt für jeden Befehl.
+
+- **Globale Optionen stehen VOR dem Befehl.** `agenteye --json sessions` ist korrekt; `agenteye sessions --json` ist ein Verwendungsfehler. Die globalen Optionen sind `--json`, `--base-url`, `--org`, `--token`, `--insecure`/`--secure`, `--timeout`, `--quiet` und `--no-color`.
+- **`--json` gibt reines JSON nach stdout aus, und sonst nichts.** Lesbare Statuszeilen, Warnungen und Fehler gehen an **stderr**, sodass eine `--json`-stdout-Erfassung sauber in `jq` geleitet werden kann, auch wenn eine Statuszeile angezeigt wird. Ohne `--json` erhältst du eine umrahmte, kolorierte Ansicht für menschliche Augen.
+- **Erkunden mit `--help`.** Jeder Befehl und Unterbefehl hat `--help` (und das `-h`-Alias): `agenteye -h`, `agenteye sessions -h`, `agenteye keys create -h`. Die oberste Hilfe listet auch die Exit-Codes und globalen Optionen auf. Es gibt keine globale maschinenlesbare Oberflächenauflistung; verwende `--help` pro Befehl sowie die domänenspezifischen `agenteye query schema` und `agenteye settings schema` für diese zwei Register.
+- **Bestätigungen werden für Skripte und Agenten automatisch übersprungen.** Erstell-/Aktualisierungs-/Löschbefehle fragen in einem interaktiven Terminal nach, ob du sicher bist, **überspringen diese Abfrage aber automatisch unter `--json` oder wenn stdin kein TTY ist** (ein TTY ist eine interaktive Terminalsitzung; eine Pipe oder ein CI-Runner ist keins), sodass Skripte und Agenten nie hängen bleiben. Übergib `--yes`/`-y`, um es explizit zu überspringen. Da die Abfrage für einen Agenten nicht ausgelöst wird, sollte ein Agent destruktive Aktionen vorher mit dem Menschen bestätigen.
+- **Paginierung:** Ergebnisse sind neueste zuerst und cursor-paginiert (jede Seite gibt ein Token zurück, das du zum Abrufen der nächsten verwendest). `--limit N` (Alias `-n`) begrenzt Zeilen und **standardmäßig auf 50**; `--all` paginiert automatisch (in 200-Zeilen-Chunks) **bis `--limit`**, sodass ein bloßes `--all` immer noch bei 50 stoppt. Für eine vollständige Abfrage übergib ein hohes explizites Limit: `--all --limit 1000`. `--page-size N` steuert den Chunk pro Anfrage (max. 200); `--cursor <id>` setzt ab dem `next_cursor` einer vorherigen Seite fort.
+- **Zeitfilter:** `--since` nimmt ein relatives Zeitfenster: `15m`, `1h`, `6h`, `24h`, `7d` oder `all` (die Voreinstellungen des Dashboards). Für einen längeren oder benutzerdefinierten Bereich (z. B. die letzten 30 Tage) verwende `--from`/`--to`: explizite ISO-8601-UTC-Zeitstempel **mit `T` und einer Zeitzone** (z. B. `2026-06-01T00:00:00Z`), die `--since` überschreiben. Ein mit Leerzeichen getrennter oder zeitzonenloser Wert ist ein Verwendungsfehler.
+- **`--fields a,b,c`** (bei `events`, `sessions`, `evals`, `errors`) schränkt die Ausgabe auf diese Schlüssel ein, sowohl für die Tabelle als auch für `--json`. Unbekannte Namen werden mit der gültigen Liste abgewiesen – eine einfache Methode, Feldnamen zu entdecken.
+- **`--file payload.json`** (oder `--file -`, um stdin zu lesen) liefert einen vollständigen JSON-Request-Body, wenn eine Ressource eine komplexe Form hat (bei `alerts create/update`, `settings set` und `users create/update`). SQL für gespeicherte Abfragen verwendet stattdessen `--sql @file.sql`.
+- **Mehrwertige Filter** sind kommagetrennt → als Menge abgeglichen (Union innerhalb eines Filters, UND über Filter hinweg): `--event-type tool_use,tool_result`. Click-Optionen sind nicht variadisch, daher schlägt `--add a b` fehl. Verwende `--add a,b`, wiederhole das Flag (`--add a --add b`) oder setze Anführungszeichen (`--add "a b"`).
+
+---
+
+## Befehlsreferenz
+
+### Die 5 häufigsten Befehle
+
+Die meisten alltäglichen Aufgaben laufen über eine Handvoll Lesebefehle. Fange hier an und greife bei Bedarf auf die vollständige Oberfläche unten zurück:
+
+| Befehl | Was er tut | Ausprobieren |
+|---|---|---|
+| `sessions` | Eine Zeile pro Agent-Run: Zeit, Umgebung, Agent, Status, neuester Score. | `agenteye --json sessions --since 24h --status error` |
+| `events` | Der rohe schrittweise Verlauf innerhalb eines Runs (mit `--full` für Payloads). | `agenteye --json events --session-id run-001 --all` |
+| `evals` | Evaluierungsergebnisse und Scores; `--aggregate` fasst sie zusammen. | `agenteye --json evals --aggregate --since 7d --env prod` |
+| `errors` | Nur die fehlerhaften Events; `--aggregate` für Zählungen nach Typ. | `agenteye --json errors --since 24h --aggregate` |
+| `list` | Gültige Filterwerte entdecken (Agenten, Umgebungen, Modelle, …). | `agenteye list agents` |
+
+### Alles, was die CLI kann
+
+Die vollständige Oberfläche folgt. Die CLI hat **18 Top-Level-Befehle**. Alle Lesebefehle akzeptieren `--json` und die globalen Optionen oben; führe `agenteye <command> -h` (oder `<command> <subcommand> -h`) für die vollständige Flag-Liste und JSON-Form eines Befehls aus.
+
+### Identität: `login` · `logout` · `whoami` · `orgs` · `version` · `help`
+
+```bash
+agenteye login --email you@example.com [--org acme]   # emailed one-time code; saves the session
+agenteye logout                                       # clear the saved session on this machine
+agenteye whoami                                       # current user, active org, permissions
+agenteye version                                      # print the CLI version (same as --version)
+agenteye help                                         # top-level help (same as --help)
+```
+
+`orgs` prüft und wechselt den aktiven Tenant:
+
+```bash
+agenteye orgs list        # your orgs + your role in each (active one marked)
+agenteye orgs switch acme # change the saved active org (omit the slug to pick from a list on a TTY)
+agenteye orgs current     # identity card for the active org
+agenteye orgs perms       # your permissions in the active org, grouped by resource
+```
+
+### Beobachten (nur lesend): `events` · `sessions` · `evals` · `errors` · `list`
+
+Keiner dieser Befehle benötigt eine Bestätigung. Gemeinsame Filter: `--session-id`, `--agent-id`, `--env` (**nicht** `--environment`) und der Zeitbereich (`--since` / `--from` / `--to`).
+
+```bash
+# events (alias: the raw per-step trail), newest first
+agenteye --json events --session-id run-001 --event-type tool_use,tool_result --all --limit 1000
+agenteye --json events --since 1h --search timeout --all | jq '.events[].payload'
+
+# sessions: one row per agent run (time/env/agent/session/status; no score filtering)
+agenteye --json sessions --since 24h --status error
+agenteye --json sessions --agent-id checkout-bot --env prod --all --limit 1000
+
+# evals: evaluation results + scores; --score filters by metric, --aggregate rolls up
+agenteye --json evals --score helpfulness:0.5..0.8 --score tool_efficiency:..0.3
+agenteye --json evals --aggregate --since 7d --env prod        # status mix + per-key score stats
+
+# errors: errored events; --aggregate for counts/sessions/agents/last-seen
+agenteye --json errors --since 24h --aggregate
+agenteye --json errors --since 24h --error-type timeout --all --limit 1000
+
+# list: discover valid filter values before you filter
+agenteye list envs        # also: agents event_types score_filters models hooks tools error_types
+```
+
+`--score KEY:MIN..MAX` (bei **`evals`**, nicht `sessions`) ist wiederholbar und UND-kombiniert; jede Grenze ist optional (`..0.5` bedeutet ≤ 0,5, `0.9..` bedeutet ≥ 0,9). Bis zu 20 Score-Filter pro Anfrage. `evals --scores-full` ist ein Anzeigeformat-Flag **nur für die menschliche Tabelle**; es zeigt jedes Score-Paar anstelle der ersten wenigen plus einer `+N`-Zählung. Es hat keine Auswirkung unter `--json`, das immer das vollständige Score-Objekt zurückgibt. Um **eine Session von Anfang bis Ende zu lesen**, kombiniere den Event-Verlauf mit seiner Evaluierung:
+
+```bash
+agenteye --json events --session-id run-001 --all --limit 1000 | jq '.events[] | {ts, event_type}'
+agenteye --json evals  --session-id run-001                       # its scores + status
+```
+
+### Verwalten (berechtigungsgesteuert): `keys` · `users` · `settings` · `alerts` · `incidents`
+
+**`keys`**: API-Keys. Das Secret wird lokal generiert, an den Server gesendet (der nur einen Hash speichert) und beim Erstellen/Regenerieren **einmalig angezeigt**; erfasse es sofort. Mit `--json` erscheint es nur im Feld `key`. Referenziert nach **Name**.
+
+```bash
+agenteye keys list                                   # active keys first, then revoked
+agenteye keys show ci-bot
+agenteye keys create ci-bot --add events:read.add    # scope to what you need; prints the secret ONCE
+agenteye keys create ops --permission-set standard --remove queries:run   # seed a preset, then trim
+agenteye keys update ci-bot --add evaluations:read --yes
+agenteye keys regenerate ci-bot --yes                # rotate the secret (the old one stops working)
+agenteye keys disable ci-bot --yes                   # revoke
+```
+
+Berechtigungen funktionieren als `(permission-set ∪ --add) − --remove`. Tokens sind `slug:action` (z. B. `events:read`) oder `slug:action.action`, um mehrere für eine Ressource zu erweitern (`events:read.add` → `events:read`, `events:add`). Voreinstellungen: `read-only`, `standard`, `admin`. Rein menschliche Berechtigungen (`keys:update`) können keinem Key gewährt werden.
+
+**`users`**: Org-Mitglieder, referenziert per **E-Mail** (eine UUID-ID wird ebenfalls akzeptiert).
+
+```bash
+agenteye users list [--active-only]
+agenteye users show dev@corp.com
+agenteye users create dev@corp.com --permission-set standard
+agenteye users update dev@corp.com --add alerts:write --remove queries:delete   # predicts + confirms
+agenteye users disable dev@corp.com --yes            # has protected/self guards
+agenteye users enable dev@corp.com
+```
+
+**`settings`**: Ein festes Register (du liest und ändert vorhandene Schlüssel; du kannst keine neuen erstellen).
+
+```bash
+agenteye settings list                               # key · value · type · updated (secrets masked)
+agenteye settings schema                             # what each key accepts (type · range · description)
+agenteye settings set session_ttl_secs --value 86400 --yes
+```
+
+**`alerts`**: Alert-Definitionen, referenziert nach **Name**. `create` nimmt einen positionale NAME plus Flags oder einen vollständigen JSON-Body via `--file`.
+
+```bash
+agenteye alerts list
+agenteye alerts show high-errors
+agenteye alerts create high-errors --file alert.json          # NAME is required (positional)
+agenteye alerts update high-errors --severity critical --yes
+agenteye alerts test high-errors --yes                        # fire a test notification
+agenteye alerts delete high-errors --yes
+```
+
+**`incidents`**: Alert-Incidents, referenziert per ID (Kurzformen akzeptiert). `show` gibt das vollständige Aktivitätsprotokoll aus; lies es vor dem Handeln.
+
+```bash
+agenteye incidents list --state firing                # also: acknowledged, resolved
+agenteye incidents count
+agenteye incidents show <id>
+agenteye incidents ack <id>
+agenteye incidents assign <id> you@corp.com           # assignee must be an operator
+agenteye incidents resolve <id> --yes
+agenteye incidents open --alert-id <id> --severity critical    # open one manually against an alert
+agenteye incidents comment-add <id> "root cause: upstream 5xx"
+agenteye incidents comment-list <id> ; agenteye incidents comment-delete <id> <comment-id>
+agenteye incidents subscribe <id> ; agenteye incidents unsubscribe <id> ; agenteye incidents subscribers <id>
+```
+
+### Analysen & Assistent: `query` · `agent`
+
+**`query`**: Gespeichertes SQL gegen deinen Analyse-Store plus einen Ad-hoc-Runner. Gespeicherte Abfragen werden nach **Name** referenziert; das SQL wird serverseitig validiert (nur SELECT/WITH, Statement-Timeout, Zeilenlimit).
+
+```bash
+agenteye query schema [TABLE]                         # column layout of the analytics views
+agenteye query run --sql "select count(*) from analytics.events"
+agenteye query run errs --arg prod --limit 100        # run a saved query + a positional $1
+agenteye query list ; agenteye query show errs
+agenteye query create errs --sql @errs.sql --description "errored events (24h)"
+agenteye query update errs --sql @errs.sql --yes ; agenteye query delete errs --yes
+```
+
+**`agent`**: Kommuniziert mit dem eingebauten **KI-Assistenten** (demselben schreibgeschützten Analysten, mit dem du im Dashboard chatten kannst). Chats werden per Kurz-Chat-ID referenziert (Präfix-aufgelöst).
+
+```bash
+agenteye agent health                                 # is the AI assistant configured/reachable
+agenteye agent models                                 # models you can pass to --model (default marked)
+agenteye agent ask "which agents errored most in the last day?"    # starts a chat; prints its short id
+agenteye agent ask --chat <short-id> "and which tools did they call?"   # continue that chat
+agenteye agent chats ; agenteye agent show <short-id>
+agenteye agent rename <short-id> --title "error triage" ; agenteye agent delete <short-id>
+```
+
+---
+
+## Exit-Codes
+
+| Code | Bedeutung |
+|---|---|
+| 0 | Erfolg |
+| 1 | Unerwarteter Fehler (z. B. Dashboard gab einen 5xx zurück) |
+| 2 | Verwendungsfehler (ungültige Argumente, unbekannter Befehl/Flag, Namenskollision) |
+| 3 | Dashboard nicht erreichbar |
+| 4 | Nicht angemeldet oder Session abgelaufen; führe `agenteye login` aus |
+| 5 | Authentifiziert, aber dein Konto verfügt nicht über die erforderliche Berechtigung (die Meldung nennt sie) |
+| 6 | Die angeforderte Ressource wurde nicht gefunden (z. B. unbekannte Session- oder Incident-ID) |
+
+Diese machen die CLI sicher skriptfähig: Ein Coding-Agent kann bei `4` darauf reagieren, dich zur erneuten Authentifizierung aufzufordern, oder bei `5` die fehlende Berechtigung anzeigen. Siehe [CLI-Rezepte für Agenten](/de/agenteye/cli-recipes) für Exit-Code-Behandlungsmuster und JSON-Ausgabeformen.
+
+---
+
+## Nächste Schritte
+
+- **[CLI-Rezepte für Agenten](/de/agenteye/cli-recipes)**: Kopierfertige Abfragemuster, `jq`-Einzeiler, `--fields`-Projektionen, Exit-Code-Behandlung und JSON-Ausgabeformen – geschrieben für Coding-Agenten, die die CLI steuern.
+- **[CLI-Agent-Skill](/de/agenteye/cli-skill)**: Paketiere diese CLI als installierbaren Claude Code / Codex-*Skill*, damit ein Coding-Agent Failproof AI Observability über einfache Textanfragen steuert.
+- **[API-Keys](/de/agenteye/api-keys)**: Das Berechtigungsmodell hinter `keys create --add …`.
+- **[KI-Assistent](/de/agenteye/assistant)**: Den Assistenten aktivieren, mit dem `agent ask` kommuniziert.

package/.next/standalone/docs-old/de/agenteye/codex-capture.mdx

@@ -0,0 +1,55 @@
+---
+title: "Codex-Sitzungsaufzeichnung"
+description: "Leite die lokalen OpenAI Codex-Sitzungen deines Teams als gewöhnliche Sessions und Events in AgentEye weiter – ohne Änderungen an ihrer Arbeitsweise."
+---
+
+Deine Entwickler nutzen OpenAI Codex bereits täglich. Die Codex-Sitzungsaufzeichnung bringt diese Coding-Sessions als gewöhnliche Sessions und Events in AgentEye, sodass du sie durchsuchen, wiedergeben und zusammen mit allem anderen, was du beobachtest, auswerten kannst. Sie ergänzt das [Python SDK](/de/agenteye/python-sdk): Das SDK instrumentiert Agenten, die du selbst schreibst, während dieses Feature die Codex-Arbeit deines Teams aufzeichnet – ohne dass sich an deren Arbeitsweise etwas ändert.
+
+Ein kleiner Hintergrundkollektor liest Codex' lokale Sitzungstranskripte, während sie geschrieben werden, und überträgt sie an AgentEye. Ein Kollektor pro Maschine erfasst alle lokalen Codex-Oberflächen gleichzeitig – es ist keine oberflächenspezifische Einrichtung erforderlich.
+
+Derselbe Kollektor erfasst auch andere Agenten – siehe [OpenClaw](/de/agenteye/openclaw-capture) und [Hermes](/de/agenteye/hermes-capture). Aktiviere jede Variante, die du verwendest; ein einzelner Kollektor kann mehrere gleichzeitig aufzeichnen.
+
+---
+
+## Was aufgezeichnet wird
+
+Jede Codex-Oberfläche, die **lokal** ausgeführt wird, erzeugt dieselben Sitzungstranskripte auf der Festplatte, und der Kollektor liest alle davon:
+
+- das Codex **CLI** und `codex exec`
+- die **VS Code / IDE-Erweiterung**
+- die **Desktop-App**, wenn sie eine Sitzung lokal ausführt
+
+Jede Codex-Sitzung wird zu einer AgentEye-[Session](/de/agenteye/sessions); ihre Nutzer- und Assistentennachrichten, das Reasoning, Tool-Aufrufe, Tool-Ergebnisse und der Token-Verbrauch werden zu den entsprechenden [Events](/de/agenteye/event-stream). Die Oberfläche, von der die jeweilige Sitzung stammt (CLI, IDE oder Desktop), wird festgehalten, damit du sie unterscheiden kannst.
+
+> **Cloud-Sitzungen werden nicht aufgezeichnet.** Die Desktop-App führt Sitzungen zunehmend in der Codex-Cloud aus und speichert lokal nur deren Metadaten – es gibt kein lokales Transkript zum Lesen. Nur lokal ausgeführte Sitzungen werden aufgezeichnet.
+
+---
+
+## Aktivierung
+
+Die Aufzeichnung ist standardmäßig deaktiviert. Installiere den Kollektor mit einem API-Schlüssel, der die Berechtigung `events:add` besitzt (siehe [API-Schlüssel](/de/agenteye/api-keys)), und aktiviere die Codex-Aufzeichnung:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --codex-enabled
+```
+
+Damit wird der Kollektor installiert, als Hintergrunddienst registriert und die Aufzeichnung gestartet. Prüfe, ob er läuft:
+
+```bash
+agenteye-collector health
+```
+
+Beim ersten Start werden deine vorhandenen Codex-Sitzungen einmalig nachgefüllt, danach werden neue Aktivitäten innerhalb von Sekunden übertragen. Die Dateien von Codex werden ausschließlich gelesen – niemals verändert, verschoben oder gelöscht – und jede Sitzung wird genau einmal übertragen, auch nach einem Neustart.
+
+---
+
+## Wo die Daten erscheinen
+
+Aufgezeichnete Sitzungen erscheinen unter **Sessions** und ihre Events im **Events**-Stream – genauso wie bei jedem anderen beobachteten Agenten. Damit funktionieren [Session-Replay](/de/agenteye/sessions), [Suche](/de/agenteye/queries), [Auswertungen](/de/agenteye/evaluations) und [Alerts](/de/agenteye/alerts) für sie ganz normal. Filtere nach dem Codex-Agenten, um nur diese anzuzeigen.
+
+---
+
+## Datenschutz
+
+Codex-Transkripte enthalten die vollständige Sitzung – einschließlich Befehlsausgaben, Dateiinhalten und allem, was Codex gelesen oder geschrieben hat – und können sensible Informationen enthalten. Aufgezeichnete Sitzungen werden unverändert übertragen. Aktiviere die Aufzeichnung daher nur auf Maschinen und für Teams, bei denen das Zentralisieren dieser Inhalte in AgentEye angemessen ist, und weise dem Kollektor ausschließlich einen Schlüssel mit dem Umfang `events:add` zu. Unter [Sicherheit](/de/agenteye/security) erfährst du, wie deine Daten isoliert aufbewahrt werden.

package/.next/standalone/docs-old/de/agenteye/concepts.mdx

@@ -0,0 +1,87 @@
+---
+title: "Konzepte"
+description: "Das Vokabular hinter Failproof AI Observability — Events, Sessions, Evaluierungen, Audits, Findings und Incidents — an einem Ort definiert."
+---
+
+
+Diese Seite definiert das Vokabular, das Failproof AI Observability verwendet. Wenn ein Begriff in einem anderen Leitfaden unbekannt ist, wird er hier erklärt. Sie müssen ihn nicht von Anfang bis Ende lesen: Überfliegen Sie ihn, oder kehren Sie zurück, wenn Sie ein Wort genauer nachschlagen möchten.
+
+---
+
+## Das Datenmodell
+
+**Event**
+Die kleinste Dateneinheit. Ein Event zeichnet einen einzelnen Schritt auf, den Ihr Agent ausgeführt hat: ein `tool_use`, ein `model_request`, ein `hook_completed`, ein `error` usw. Ihr Agent gibt Events über das [Python SDK](/de/agenteye/python-sdk) aus; sie erscheinen in Echtzeit auf der **Events**-Seite.
+
+**Session**
+Ein einzelner Agent-Lauf, identifiziert durch eine `session_id`. Eine Session umfasst alle Events, die diese ID teilen, zusammengefasst in einer einzelnen Zeile auf der **Sessions**-Seite und als Ausführungsgraph auf ihrer Detailseite dargestellt. Eine Session beginnt üblicherweise mit `agent_start` und endet mit `agent_end`.
+
+**Agent**
+Ein benannter Akteur innerhalb eines Laufs, identifiziert durch eine `agent_id`. Ein Lauf kann mehrere Agents umfassen: zum Beispiel einen Planer, der einen Zusammenfassungs-Sub-Agenten startet. Sub-Agents tragen eine `parent_id`, die es Failproof AI Observability ermöglicht, sie in eigenen Spuren im Ausführungsgraph darzustellen.
+
+**Environment**
+Eine Bezeichnung für den Ort, an dem der Lauf stattgefunden hat: `production`, `staging`, `dev`. Sie legen sie einmalig bei der Konfiguration des SDK fest. Fast jede Dashboard-Seite kann nach Environment gefiltert werden.
+
+**Context-Window-Auslastung**
+Der prozentuale Anteil des Context-Windows eines Modells, den eine Antwort verbraucht hat. Failproof AI Observability versieht `model_response`-Events bei erkannten Modellen mit diesem Wert, sodass das Wachstum von Prompts und bevorstehende Kompaktierungen direkt im Event-Stream sichtbar sind.
+
+---
+
+## Qualität
+
+**Evaluation**
+Eine Qualitätsbewertung für eine abgeschlossene Session, die von einem Scoring-Dienst erstellt wird, den Sie selbst betreiben. Evaluierungen sind optional: Bis Sie einen Evaluator anschließen, werden Sessions aufgezeichnet, aber nicht bewertet. Jede Evaluierung kann mehrere benannte Scores enthalten (zum Beispiel `helpfulness`, `factuality`, `tool_efficiency`), jeweils mit einer kurzen Begründungsnotiz. Siehe [Evaluation suite](/de/agenteye/evaluation-suite).
+
+**Score-Key**
+Der Name einer Dimension, über die ein Evaluator berichtet, z. B. `helpfulness`. Alerts und Audits können einen bestimmten Score-Key im Zeitverlauf beobachten.
+
+**Evaluator**
+Ihr Scoring-Dienst. Failproof AI Observability übermittelt das Transkript eines abgeschlossenen Laufs per POST an ihn und speichert die zurückgegebenen Scores. Ein Standard-Evaluator wird nicht mitgeliefert; die Bewertungslogik liegt bei Ihnen.
+
+---
+
+## Fehler finden und beheben
+
+**Hook**
+Eine Sicherheitsvorkehrung oder ein Nebeneffekt, den Ihr Agent-Framework um einen Schritt herum ausführt: eine Inhaltssicherheitsprüfung, PII-Schwärzung oder eine Budget-Überwachung. Hooks geben `hook_triggered`- / `hook_completed`-Events mit einem `outcome` (allow, deny, modify) aus und haben eine eigene Observe-Seite.
+
+**Alert-Regel**
+Eine Regel, die ausgelöst wird, wenn eine Metrik einen von Ihnen festgelegten Schwellenwert überschreitet: Fehlerrate, p95-Latenz, Token-Kosten oder ein Evaluator-Score. Wenn eine Regel ausgelöst wird, öffnet sie einen Incident und benachrichtigt Ihre gewählten Kanäle (E-Mail, Slack, Webhook, im Dashboard). Siehe [Alerts](/de/agenteye/alerts).
+
+**Incident**
+Ein offenes Problem, das entsteht, wenn eine Alert-Regel ausgelöst wird. Incidents haben einen Lebenszyklus (bestätigen, zuweisen, lösen) und eine Aktivitäts-Timeline, die jede Aktion aufzeichnet. Sie können auch manuell einen öffnen.
+
+**Audit**
+Eine wiederkehrende Untersuchung (stündlich bis wöchentlich), die Ihre Logs *sitzungsübergreifend* nach Fehlermustern durchsucht, für die Sie noch keine Regel geschrieben haben: Fehler-Cluster, niedrige Scores, Latenz-Ausreißer, Tool-Call-Schleifen und Läufe, die nie abgeschlossen wurden. Während ein Alert eine Metrik überwacht, die Sie bereits kennen, zeigt Ihnen ein Audit, worauf Sie als Nächstes achten sollten. Siehe [Audits](/de/agenteye/audits).
+
+**Finding**
+Ein priorisiertes, evidenzbasiertes Ergebnis eines Audit-Laufs. Ein Finding benennt ein Muster, verlinkt auf die genauen Sessions dahinter und trägt einen Triage-Lebenszyklus (bestätigen, lösen, stummschalten, verwerfen). Failproof AI Observability dedupliziert Findings laufübergreifend, sodass ein bekanntes Muster aktualisiert wird, anstatt sich anzuhäufen.
+
+**Der KI-Assistent**
+Der im Dashboard integrierte Chat, der auf Englisch Fragen zu Ihren Agents beantwortet — basierend auf Ihren eigenen Daten. Er ist standardmäßig schreibgeschützt; alles, was er erstellt (eine gespeicherte Abfrage, ein Dashboard), erfordert eine Genehmigung, und er kann niemals löschen. Siehe [AI assistant](/de/agenteye/assistant).
+
+---
+
+## Betrieb
+
+**Organisation (Tenant)**
+Ein isolierter Arbeitsbereich. Eine Failproof AI Observability-Instanz kann viele Organisationen hosten, jede mit eigenen Benutzern, Schlüsseln und Daten. Jede Dashboard-URL ist unter Ihrem Org-Slug (`/<org-slug>/…`) eingeschränkt.
+
+**Collector**
+`agenteye-collector`, der schlanke Daemon, der auf jedem Agent-Rechner läuft, die Events bündelt, die das SDK auf die Festplatte schreibt, und sie an den Server übermittelt.
+
+**API-Key**
+Ein bereichsbeschränktes Token, das einen Client gegenüber dem Server authentifiziert. Keys tragen granulare Berechtigungen (zum Beispiel `events:add` für den Collector, schreibgeschützte Bereiche für einen Dashboard-Key). Siehe [API keys](/de/agenteye/api-keys).
+
+**Server**
+Der Ingest- und API-Dienst. Er nimmt Events entgegen, speichert den Betriebszustand in Ihren Datenbanken und stellt das Dashboard und die CLI bereit.
+
+**Dashboard**
+Die Web-Oberfläche. Jede Seite ist auf eine Organisation beschränkt und liest über die API des Servers.
+
+---
+
+## Nächste Schritte
+
+- [Overview](/de/agenteye/overview): Wie diese Teile zusammenpassen.
+- [Observability](/de/agenteye/observability): Die Observe-Oberflächen (Events, Sessions, Models, Tools, Hooks, Errors).

package/.next/standalone/docs-old/de/agenteye/dashboards.mdx

@@ -0,0 +1,46 @@
+---
+title: "Dashboards"
+description: "Verwandeln Sie Ihre Live-Agentendaten in ein gemeinsames Bild, das Ihr gesamtes Team im Blick behält."
+---
+
+
+Verwandeln Sie Ihre Live-Agentendaten in ein gemeinsames Bild, das Ihr gesamtes Team im Blick behält. Pinnen Sie die wichtigsten Abfragen als Diagramme, und alle sehen auf Anhieb dieselben Zahlen – ohne eine einzige Abfrage erneut ausführen zu müssen.
+
+![Ein Dashboard aus gespeicherten Abfragen: eine Ereignisse-pro-Stunde-Linie, ein Fehler-nach-Typ-Balken, ein Latenz-Flächendiagramm und Tokens nach Modell](/agenteye/images/dashboard-fleet.png)
+
+*Ein Board, vier gespeicherte Abfragen: Ereignisse pro Stunde, Fehler nach Typ, Latenz und Tokens nach Modell.*
+
+## Alle sehen dieselbe Wahrheit
+
+Schluss mit Screenshots in Chat-Nachrichten und dem fünfmaligen täglichen Wiederholen derselben Abfrage. Ein Dashboard ist ein gemeinsames, organisationsweites Board, das jedes Teammitglied in exakt derselben Ansicht öffnen kann. Wenn sich die zugrunde liegenden Daten ändern, passen sich die Diagramme automatisch an – das Board ist also immer aktuell, und niemand streitet mehr über veraltete Zahlen.
+
+Das Fleet-Dashboard oben ist ein guter Ausgangspunkt für den täglichen Betrieb:
+
+- eine **Ereignisse-pro-Stunde**-Linie, um den Durchsatz zu beobachten und plötzliche Einbrüche zu erkennen
+- ein **Fehler-nach-Typ**-Balken, damit die häufigsten Fehlerkategorien sofort ins Auge springen
+- ein **Latenz**-Flächendiagramm, damit Verlangsamungen sichtbar werden, bevor Nutzer sich beschweren
+- eine **Tokens-nach-Modell**-Aufschlüsselung, damit die Kosten stets im Blick bleiben
+
+Ihre Boards finden Sie unter `/<org-slug>/dashboards`.
+
+## Gespeicherte Abfragen pinnen
+
+Jede Kachel beginnt als gespeicherte Abfrage. Erstellen und speichern Sie die gewünschte Abfrage in der [Queries](/de/agenteye/queries)-Bibliothek (mit integrierten Voreinstellungen und eigenen Abfragen über Ihre Ereignisse und Auswertungen), und pinnen Sie sie dann als passendes Diagramm auf ein Dashboard: eine **Linie** für Trends über die Zeit, ein **Balken** für Kategorienvergleiche, eine **Fläche** für Volumina oder ein **Kreisdiagramm** für Anteile.
+
+Da eine Kachel lediglich Ihre gespeicherte Abfrage als Diagramm darstellt, müssen Sie nichts manuell synchronisieren. Aktualisieren Sie die Abfrage einmal, und jedes Dashboard, das sie verwendet, wird automatisch aktualisiert.
+
+## Qualität im Blick behalten, nicht nur Volumen
+
+Das Volumen zeigt Ihnen, dass die Agenten beschäftigt sind. Die Qualität zeigt Ihnen, ob sie ihre Aufgabe tatsächlich erfüllen. Richten Sie ein Dashboard auf Ihre [Auswertungs-Scores](/de/agenteye/evaluations) aus, und Sie erhalten ein Board, das verfolgt, wie gut die Ausführungen im Laufe der Zeit laufen – sodass ein Qualitätsrückgang als Einbruch im Diagramm erscheint und nicht als böse Überraschung eines Kunden.
+
+![Ein qualitätsorientiertes Dashboard aus gespeicherten Auswertungsabfragen](/agenteye/images/dashboard-quality.png)
+
+*Ein Qualitäts-Board hält Ihre Auswertungs-Scores stets im Vordergrund, direkt neben den operativen Kennzahlen.*
+
+Halten Sie ein Betriebs-Board und ein Qualitäts-Board nebeneinander, und Ihr Team hat einen einzigen Ort, um sowohl „Funktioniert es?" als auch „Ist es gut?" zu beantworten – ohne dass jemand eine Abfrage erneut ausführen muss.
+
+## Verwandtes
+
+- [Queries](/de/agenteye/queries): Erstellen und speichern Sie die Abfragen, die zu Ihren Kacheln werden.
+- [Evaluations](/de/agenteye/evaluations): Bewerten Sie Ihre Ausführungen, um die Qualität über die Zeit abzubilden.
+- [Alerts](/de/agenteye/alerts): Wandeln Sie einen Schwellenwert für eine dieser Metriken in eine Benachrichtigung um.

package/.next/standalone/docs-old/de/agenteye/error-tracking.mdx

@@ -0,0 +1,41 @@
+---
+title: "Fehlerverfolgung"
+description: "Sehen Sie jeden Fehler Ihrer Agenten an einem Ort, gruppiert, damit ein Fehlerstoß als ein einziges Problem erscheint."
+---
+
+
+Sehen Sie jeden Fehler Ihrer Agenten an einem Ort, gruppiert, damit ein Fehlerstoß als ein einziges Problem erscheint. Sie erhalten einen Klick-Pfad von „etwas ist rot" bis zum genauen Lauf, der abgebrochen ist, ohne einen Live-Feed durchscrollen zu müssen.
+
+![Die Fehlerseite: ein Histogramm der Fehler über die Zeit über gruppierten roten Fehlerzeilen, jede mit einer Ein-Klick-Schaltfläche „+ alert"](/agenteye/images/errors.png)
+*Die Fehlerseite: ein Histogramm der Fehler über die Zeit, wobei wiederkehrende Fehler in einer Zeile pro Vorfall zusammengefasst werden.*
+
+## Jeder Fehler, bereits für Sie gesammelt
+
+Wenn ein Agent abstürzt, sollten Sie keinen Live-Event-Stream durchscrollen müssen, um rote Zeilen zu finden, bevor sie verschwinden. Die **Fehlerseite** übernimmt das Sammeln für Sie. Sie bündelt alles, was das Dashboard rot markieren würde, auf einer einzigen Triage-Oberfläche – das Erste, was Sie sehen, ist, was fehlschlägt, nicht wo Sie danach suchen müssen.
+
+Und sie erfasst mehr als die offensichtlichen Fehler. Neben expliziten `error`-Events macht Failproof AI Observability auch die stillen Fehler sichtbar: Jedes `tool_result`, `hook_completed` oder `agent_end`, dessen Payload einen Fehler enthält, wird hier angezeigt. Ein Tool, das einen Fehler zurückgegeben hat, oder ein Hook, der fehlerhaft beendet wurde, entgeht Ihnen nicht mehr, nur weil keine laute Exception ausgelöst wurde.
+
+Am oberen Rand zeigt ein Histogramm Fehler über die Zeit. Ein Blick zeigt Ihnen, ob es sich um ein stetiges Hintergrundrauschen oder um einen Anstieg handelt, der vor wenigen Minuten begann – damit wissen Sie sofort, ob Sie alles stehen und liegen lassen müssen.
+
+Wie jede Beobachtungsoberfläche ist die Fehlerseite auf Ihre Organisation begrenzt und lässt sich nach Datumsbereich, Umgebung, Agent und Session filtern. So können Sie eine flottenweit gültige Liste auf den einen Agent oder die eine Umgebung eingrenzen, die Sie tatsächlich interessiert.
+
+## Ein Vorfall, nicht hundert identische Zeilen
+
+Eine einzige defekte Abhängigkeit kann denselben Fehler hunderte Male pro Minute auslösen. Unbearbeitet ergibt das eine Wand aus nahezu identischen Zeilen, die das Wesentliche verbirgt.
+
+Failproof AI Observability fasst wiederkehrende Fehler mit derselben Session und demselben Fehlertyp in einer einzigen Zeile zusammen. Ein Fehlerstoß erscheint als ein einziger Vorfall. Sie zählen Probleme, keine Log-Zeilen – und das Signal, das wichtig ist, bleibt oben, anstatt von seinem eigenen Volumen überwältigt zu werden.
+
+## Von „etwas ist rot" zum genauen Event
+
+Klicken Sie auf eine beliebige Zeile, um direkt in die Session dieses Laufs zu gelangen, positioniert auf dem genauen Event, das fehlgeschlagen ist. Kein Kopieren von Session-IDs, kein Scrollen, um den Moment des Fehlers zu finden: Sie landen genau dort, mit dem vollständigen Ausführungsgraph auf einen Blick, sodass Sie sehen können, was der Agent in den Momenten vor dem Absturz getan hat.
+
+Wenn Sie `alerts:write`-Berechtigung haben, enthält jede Zeile auch eine **+ alert**-Schaltfläche. Klicken Sie darauf, öffnet Observability eine neue Alert-Regel, die bereits so ausgefüllt ist, dass sie denselben Fehler beim nächsten Mal erkennt. Der Vorfall, den Sie gerade triagiert haben, wird zu dem, der Sie beim nächsten Mal benachrichtigt – anstatt Sie zweimal zu überraschen.
+
+**Wo Sie es finden:** Die **Fehlerseite** befindet sich im Beobachtungsbereich des Dashboards unter `/<org-slug>/errors`.
+
+## Verwandte Themen
+
+- [Alerts](/de/agenteye/alerts): Jeden Fehler in eine Benachrichtigungsregel umwandeln.
+- [Incidents](/de/agenteye/incidents): Einen ausgelösten Alert von offen bis gelöst verfolgen.
+- [Sessions](/de/agenteye/sessions): Den vollständigen Lauf hinter einem Fehler öffnen.
+- [Audits](/de/agenteye/audits): Observability Fehlermuster in Ihren Läufen automatisch erkennen lassen.