---
titel: "Betriebsfehler"
adresse: https://docs.anvil-coder.tech/docs/betriebsfehler
beschreibung: "Deine Anwendung meldet ihre Fehler aus dem Betrieb selbst — der Posteingang sammelt und zählt sie, und du entscheidest, ob daraus ein Reparatur-Lauf wird. Am Ende steht höchstens ein Entwurfs-Pull-Request, nie ein Merge."
sprache: de
---

Dokumentation · Anbindung

Deine Anwendung meldet ihre Fehler aus dem Betrieb selbst — der Posteingang sammelt und zählt sie, und du entscheidest, ob daraus ein Reparatur-Lauf wird. Am Ende steht höchstens ein Entwurfs-Pull-Request, nie ein Merge.

Deine Anwendung meldet einen Fehler aus dem Betrieb selbst zurück — Anvil Coder sammelt ihn, zählt ihn, und du entscheidest, ob daraus ein Reparatur-Lauf wird. Am Ende steht höchstens ein **Entwurfs-Pull-Request**, nie ein Merge.

*Alle Bildschirmfotos zeigen eine Demo-Umgebung mit Beispieldaten.*

## In 15 Minuten angebunden

- **Kanal anlegen.** Im Cockpit unter **Integrationen** (oder in der Projekt-Liste über die drei Punkte → *Kanäle für Betriebsfehler*) wählst du das Projekt und legst einen Kanal an. Du bekommst dabei einen Schlüssel und die Adresse, an die gemeldet wird.

- **Schlüssel eintragen.** Der Schlüssel beginnt mit `anv_srv_` und gehört in die Konfiguration deiner Anwendung — genauso wie eine Datenbank-Zugangsdaten. Er steht **nicht** ins Repository. Wie das SDK in eine Laravel- oder Spring-Boot-Anwendung kommt, steht im Kapitel [Anvil Feed einbauen](https://docs.anvil-coder.tech/docs/anvil-feed-sdk).

- **Umgebung binden.** Ein Kanal allein nimmt noch nichts an. Binde die Umgebung, die dein SDK sendet (`production`, `staging`, …) — oder `*` für alle. Beim Anlegen wird bereits eine Bindung für `*` mit der Regel *Planen, Freigabe abwarten* gesetzt, damit die erste Meldung ankommt.

- **Einmal melden lassen.** Löse in deiner Anwendung einen Fehler aus (oder schicke die Beispiel-Anfrage aus dem [Server-Vertrag](https://docs.anvil-coder.tech/docs/anvil-feed-ingest)). Nach wenigen Sekunden steht der Vorfall im Posteingang.

**Der Schlüssel wird genau einmal angezeigt.** Gespeichert wird bei uns nur seine Prüfsumme und die ersten Zeichen, damit du ihn in der Liste wiedererkennst. Verloren heisst: sperren und einen neuen Kanal anlegen — nicht „beim Support nachfragen”.

## Der Posteingang

Gleichartige Fehler werden zusammengefasst: derselbe Dienst, dieselbe Ausnahme, dieselben obersten drei Stellen der Aufrufkette ergeben **einen** Vorfall mit einem Zähler. Ein Fehler, der zehntausendmal auftritt, füllt also nicht zehntausend Zeilen.

Die Spalte **Vorkommen** zeigt diesen Zähler. Die einzelnen Meldungen werden nach 30 Tagen gelöscht, der Zähler bleibt — deshalb kann im Detail „412 Meldungen” stehen, während nur noch sechs einzelne Meldungen gespeichert sind. Das Cockpit sagt das an der Stelle auch dazu.

Über die Status-Knöpfe oben schränkst du die Liste ein. Ohne Auswahl siehst du alle Status.

## Was die Status bedeuten

| Status | Bedeutung |
| --- | --- |
| **Beobachtet** | Angekommen, noch nicht eingeordnet. |
| **Eingeordnet** | Der Vorfall ist einem Projekt und einer Bindung zugeordnet und kommt für eine Reparatur in Frage. |
| **Wartet auf Freigabe** | Ein Reparatur-Lauf ist geplant. Er startet erst, wenn ein Mensch freigibt. |
| **Eingereiht** | Freigegeben, wartet auf einen freien Platz. |
| **Lauf läuft** | Der Reparatur-Lauf arbeitet. |
| **Entwurfs-PR offen** | Es gibt einen Pull Request — als **Entwurf**. Prüfen und zusammenführen ist Menschenarbeit. |
| **Braucht einen Menschen** | Automatisch geht es nicht weiter. Die Begründung steht daneben. |
| **Ignoriert** | Bewusst nicht bearbeitet, mit Begründung. Lässt sich wieder aufnehmen. |
| **Geschlossen** | Ein Mensch hat den Vorfall abgeschlossen. |

**Geschlossen wird immer von Hand.** Anvil Coder kann heute nicht beobachten, ob der Fehler im Betrieb aufgehört hat — also behauptet es das auch nicht.

## Ein Vorfall im Detail

Oben stehen die Kennzahlen: Status, Schwere, Projekt, Dienst, Umgebung, die erste und die letzte Version, in der der Fehler auftrat, und die Bindung, über die er hereinkam. Darunter:

- **Vorkommen** — der Zähler, eine kleine Tages-Kurve und die noch gespeicherten Einzelmeldungen mit Version, SDK und Anfrage.

- **Fehlermeldung** und **Aufrufkette** — die obersten Stellen zuerst; wo das SDK Quelltext mitgeschickt hat, lässt er sich aufklappen.

- **Reparatur-Versuche** — je Versuch der Status, der Nachweis, der Basis-Commit und der Link zum Entwurfs-PR.

### Die zwei Nachweis-Etiketten

Sie stehen **wörtlich** im Cockpit, weil sie hier erklärt werden und weil jedes freundlichere Wort mehr behaupten würde, als gemessen wurde:

- **`BUILD_GREEN`** — der Bau war grün. Mehr nicht. Ob der Fehler weg ist, weiss dieser Nachweis nicht.

- **`VERIFIED_BUILD`** — der Lauf ist sauber durchgelaufen, ein Test-Abschnitt wurde ausgeführt und das VERIFY-Gate war grün.

Es gibt **kein** Etikett „Regression bewiesen”. Ein Beweis wäre: derselbe Test schlägt auf dem alten Stand fehl und geht mit der Änderung durch. Diese Messung baut Anvil Coder heute nicht — und was nicht gemessen wird, wird auch nicht behauptet.

## Die Production-Karte im Dashboard

Solange ein Projekt seine Vorfälle **nicht** von aussen ans Dashboard meldet, füllt der Vorfall-Speicher dessen Production-Karte: offene Vorfälle stehen als „offen”, ein laufender Reparatur-Lauf und ein offener Entwurfs-PR als „in Bearbeitung”; geschlossene und ignorierte verschwinden von der Karte. Ein Vorfall, der *einen Menschen braucht*, zählt dabei als **offen** — entschärft ist daran nichts, die Maschine wartet nur.

**Pro Projekt schreibt genau eine Quelle die Karte.** Meldet dein Projekt Vorfälle bereits über die externe Dashboard-Schnittstelle (`PUT /api/ingest/dashboard/…/incidents`), behält diese Quelle die Karte — der Vorfall-Speicher überschreibt sie nicht. Zwei Schreiber auf einer Karte hiessen: der letzte gewinnt, und kein Bild ist je vollständig. Der Posteingang zeigt deine Vorfälle in beiden Fällen unverändert.

## Wer darf was

- **Jedes Mitglied** der Organisation liest den Posteingang und jeden Vorfall.

- **Eigentümer** der Organisation entscheiden: freigeben, ignorieren, an einen Menschen übergeben, wieder aufnehmen, schliessen. Ignorieren und Übergeben verlangen eine Begründung (höchstens 800 Zeichen) — sie steht später als einzige Erklärung neben dem Status.

- Kanäle anlegen, sperren und Umgebungen binden dürfen ebenfalls nur Eigentümer: ein Kanal erzeugt einen Schlüssel.

Eine Freigabe wechselt den Status **nicht sofort**. Der Reparatur-Dienst übernimmt sie bei seinem nächsten Durchlauf, in der Regel binnen 15 Sekunden.

## Umgebungen und Regeln

Eine Bindung sagt, was mit Meldungen aus **einer** Umgebung geschehen darf:

| Regel | Wirkung |
| --- | --- |
| **Nur beobachten** | Der Vorfall wird gesammelt und gezählt. Kein Lauf. |
| **Planen, Freigabe abwarten** (Voreinstellung) | Der Lauf wird geplant — die Planung wird abgerechnet — und wartet auf die Freigabe eines Menschen. |
| **Selbständig bis zum Entwurfs-PR** | Ohne Rückfrage bis zum Entwurfs-PR. Setzt zusätzlich voraus, dass das Projekt Läufe automatisch starten darf. |
| **Abgeschaltet** | Es passiert nichts. |

Meldungen aus einer Umgebung **ohne** Bindung werden angenommen und verworfen; die Antwort nennt `no_binding`. Wer eine neue Umgebung ausrollt, bindet sie vorher.

Zwei weitere Grenzen, die im Alltag auffallen:

- **Höchstens fünf Reparatur-Versuche pro Projekt in 24 Stunden.** Ist die Grenze erreicht, wird der Vorfall auf *Braucht einen Menschen* gesetzt und die Grenze benannt — er verschwindet nicht.

- **Reparieren kann Anvil Coder nur auf einem Code-Hoster, für den der Weg nachweislich funktioniert.** Ist dein Projekt woanders zu Hause, lehnt das Binden einer **reparierenden** Regel ab — *Planen, Freigabe abwarten* und *Selbständig bis zum Entwurfs-PR* — mit einem Hinweis, der die möglichen Hoster nennt. *Nur beobachten* und *Abgeschaltet* kannst du auf jedem Hoster binden: beide fassen deinen Code nicht an. So kann auch ein GitLab-Projekt seine Vorfälle sammeln und zählen lassen, ohne dass jeder davon unter *Braucht einen Menschen* landet.

## Das Tempo-Limit

Der Kanal nimmt **600 Anfragen pro Minute** an — Anfragen, nicht einzelne Meldungen. Ein SDK, das bis zu 50 Meldungen pro Anfrage bündelt, kommt damit auf 30 000 Meldungen pro Minute. Darüber antwortet der Server mit `429` und einem `Retry-After`; die SDKs halten sich daran.

Die vollständigen Regeln der Schnittstelle — Statuscodes, Ablehnungsgründe, Grössenschranken und ein `curl`-Beispiel — stehen im [Server-Vertrag des Anvil Feed](https://docs.anvil-coder.tech/docs/anvil-feed-ingest).

## Häufige Fragen

**Meine Meldungen kommen nicht an.** Prüfe der Reihe nach: Ist der Schlüssel unverändert übernommen worden (er beginnt mit `anv_srv_`)? Ist die Umgebung gebunden, die dein SDK sendet? Antwortet der Server `404`, ist die Funktion auf diesem Server nicht eingeschaltet — das Cockpit sagt das an der Karte auch so.

**Der Dienstname in meinem SDK hat sich geändert.** Der Vorfall bleibt beim Projekt des Schlüssels; der neue Name wird am Vorfall vermerkt. Ein SDK, das einmal richtig konfiguriert war, wird nicht wegen einer Umbenennung abgewiesen.

**Warum wurde mein Pull Request nicht zusammengeführt?** Weil ein Reparatur-Lauf grundsätzlich beim Entwurf endet. Das ist keine Einstellung, die man vergessen hat, sondern die Zusage dieser Funktion.