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

Was beobachtet wird

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

Workspace-Backend während der Entwicklung
Agent-Flow-Runs beim Orchestrieren von Agents
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:

Eine Status-Pille (grün = läuft, amber = restart, grau = gestoppt)
Start / Stop / Restart — nützlich um nach Dependency-Änderungen sauber neu zu starten
Live-Log-Stream — Python-Prozess-stdout/stderr, FastAPI-Request-Zeilen, Traceback-Frames
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 Errors 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.

Agent Flow: Runs & Logs

Agent-Flow-Projekte haben eigene Runs- und Logs-Tabs:

Runs: jede Workflow-Ausführung mit Status (queued / running / succeeded / failed / cancelled), Trigger-Payload, Output und Dauer
Logs: Per-Node-Execution-Logs mit Timestamps, genutztem Modell, Token-Counts, Cache-Hits und allen Tool-Calls, die der Node gemacht hat
Inbox: Messages die ein Agent für menschliche Prüfung hochgereicht hat (Decision-Required-Steps, Fehler)
Memory: persistenter State den Agents über Runs hinweg gespeichert haben

Aktive Runs erhöhen das Runs-Tab-Badge, damit du auf einen Blick siehst ob noch was läuft.

Veröffentlichte Apps

Sobald ein Projekt auf *.xaio.app (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; XAIO-Admins können sie projekt-übergreifend über das interne Monitoring-Dashboard korrelieren
Storage-Verbrauch — jedes Projekt hat eine Storage-Quota; aktuelle Nutzung in den Projekt-Einstellungen
API-Nutzung — veröffentlichte Web Apps zeigen Request-Counts und Latenz im Backend-Tab, scoped auf die Prod-Datenbank

Benachrichtigungen: bei Events gepingt werden

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

Code-Generierung abgeschlossen / fehlgeschlagen
Teammitglied beigetreten oder ausgetreten
AI Tasks niedrig
Publish erfolgreich oder fehlgeschlagen
Runner-/Workspace-Stabilitäts-Events

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

Das interne xaio-monitoring-Dashboard — ECS / RDS / Aurora / ElastiCache-Views, rohe CloudWatch-Metriken, Fehler-Funnels und Support-Ticket-Triage — ist ein reines Admin-Tool für die XAIO-Operatoren. Endnutzer sehen abgeleitete Signale (App-Health, Build-Status, AI-Task-Stand) aber nicht die darunterliegenden Infrastruktur-Metriken.