Monitoring

Workspace-Logs, Fehler veröffentlichter Apps und Benachrichtigungs-Kanäle.

Was beobachtet wird

In Airbuild kannst du vier Ebenen beobachten — wähle die, die zu deiner Frage passt:

• Workspace-Backend während der Entwicklung
• Preview- & Build-Fehler aus Browser-Konsole und Build
• Veröffentlichte Apps nach dem Go-Live
• Projekt-Events als Benachrichtigungen

Workspace: Backend-Tab

Web-App- und Platform-Builder-Projekte haben einen Backend-Tab im Workspace. Er zeigt:

• Ein Logs-Unter-Tab mit dem laufenden Stream — Python-stdout/stderr, FastAPI-Request-Zeilen, Traceback-Rahmen. Die letzten 1000 Zeilen werden vorgehalten, ältere Ausgabe wird auf Anforderung nachgeladen
• Ein API-Unter-Tab mit den bereitgestellten Endpunkten und ein Database-Unter-Tab mit dem Datenbank-Browser des Projekts
• Den internen Port (8080), auf dem das Backend im Workspace-Container läuft

Fehler die hier hochkommen sind auch dem Agent zugänglich: ein Klick auf Fix with AI schickt den Stack-Trace als context-injected Message in den Chat, damit der Agent das patchen kann ohne dass du Log-Zeilen copy-pasten musst.

Workspace: Preview & Build-Fehler

Der Preview-Tab zeigt Vite-Build-Fehler und Runtime-Fehler aus der Browser-Konsole. Ein rotes Badge am Tab zählt ungelöste Fehler; das Badge sitzt auf z-20 mit Halo-Ring, damit es lesbar bleibt — egal welcher Tab aktiv ist.

Backend Pre-Flight Validation läuft vor jedem Publish — wenn eine Backend-Route bei einem Smoke-Check 500 wirft, wird der Publish blockiert und die fehlschlagende Route + Fehler im Publish-Dialog gezeigt.

Build Auto-Fixer: wenn npm run build beim Publish fehlschlägt, versucht ein kleineres Modell den Fehler zu patchen (bis zu 2 Retries) bevor es dich involviert. Konversation und Diff bleiben in der Publish-Historie, damit du sehen kannst was geändert wurde.

Veröffentlichte Apps

Sobald ein Projekt auf *.airbuild.space (oder deiner eigenen Domain) live ist, geht das Monitoring weiter:

• Build-Historie im Publish-Dialog — jede veröffentlichte Version mit deployed Commit-SHA, wer ausgelöst hat, und Ergebnis
• Error-Tracking — Runtime-Fehler vom Lambda-Handler landen in CloudWatch und werden im Workspace gezeigt
• Storage-Verbrauch — jedes Projekt hat eine Storage-Quota; aktuelle Nutzung in den Projekt-Einstellungen
• Log-Stream — die Monitoring-Ansicht unter Deployments zeigt die CloudWatch-Zeilen deines veröffentlichten Backends für ein gewähltes Zeitfenster (1 Stunde bis 7 Tage oder ein eigener Bereich), mit Textsuche und Fehler-/Warn-Klassifizierung. Request-Counts und Latenz sind für Projekt-Owner noch nicht sichtbar

Benachrichtigungen: bei Events gepingt werden

Notification-Channels unter Einstellungen > Benachrichtigungen konfigurieren, um Alerts zu bekommen bei:

• Code-Generierung abgeschlossen / fehlgeschlagen
• Organisations- oder Workspace-Einladung
• Neues Mitglied beigetreten
• AI Tasks niedrig
• Publish erfolgreich oder fehlgeschlagen

Kanäle: E-Mail (immer verfügbar), Slack, Discord, Telegram. Jede Notification-Art kann pro Kanal an-/ausgeschaltet werden.

Was Projekt-Owner (noch) nicht sehen

Airbuild betreibt ein eigenes Betriebs-Monitoring — Infrastruktur-Metriken der Plattform, flottenweite Fehler-Funnels und Support-Triage — als internes Admin-Werkzeug, nicht als Teil des Produkts. Als Projekt-Owner siehst du die abgeleiteten Signale: die Health deiner veröffentlichten App, deinen Build-Status, deinen Log-Stream und deinen AI-Task-Stand — nicht die Plattform-Metriken darunter.