Monitoring

What's monitored

Across XAIO you can observe four layers — pick the one that matches what you're trying to answer:

• Workspace backend while iterating in dev
• Agent Flow runs while orchestrating agents
• Published apps once you've shipped
• Project events delivered as notifications

Workspace: backend tab

Web App and Platform Builder projects expose a Backend tab in the workspace. It shows:

• A status pill (green = running, amber = restarting, gray = stopped)
• Start / Stop / Restart controls — useful when you want to force a clean restart after changing dependencies
• A live log stream — Python process stdout/stderr, FastAPI request lines, traceback frames
• The internal port (8080) the backend runs on inside the workspace container

Errors that bubble up here are also exposed to the agent: clicking Fix Errors sends the stack trace into the chat as a context-injected message so the agent can patch it without you copy-pasting log lines.

Workspace: preview & build errors

The Preview tab surfaces Vite build errors and runtime errors caught in the browser console. A red badge on the tab counts unresolved errors; the badge sits at z-20 with a halo ring so it's readable regardless of which tab is active.

Backend Pre-Flight Validation runs before every publish — if any backend route 500s during a smoke check, the publish is blocked and the failing route + error appear in the publish dialog.

Build Auto-Fixer: if npm run build fails during publish, a smaller model takes a shot at patching the error (up to 2 retries) before bothering you. The conversation and the diff stay in the publish history so you can see what was changed.

Agent Flow: runs & logs

Agent Flow projects have dedicated Runs and Logs tabs in the workspace toolbar:

• Runs: every workflow execution with status (queued / running / succeeded / failed / cancelled), trigger payload, output, and duration
• Logs: per-node execution logs with timestamps, model used, token counts, cache hits, and any tool calls the node made
• Inbox: messages an agent surfaced for human review (decision-required steps, errors)
• Memory: persistent state the agents have stored across runs

Active runs increment the Runs tab badge so you can see at a glance whether something is still in flight.

Published apps

Once a project is live at *.xaio.app (or your custom domain), monitoring continues:

• Build history in the Publish dialog — every published version with the deployed commit SHA, who triggered it, and the result
• Error tracking — runtime errors from your Lambda handler are captured in CloudWatch and surfaced in the workspace; XAIO admins can correlate them across projects via the internal monitoring dashboard
• Storage usage — every project has a storage quota; you see your current usage in Project Settings
• API usage — published Web Apps expose request counts and latency in the Backend tab, scoped to the prod database

Notifications: getting pinged about events

Configure notification channels under Settings > Notifications to be alerted on:

• Code generation completed / failed
• Team member joined or left
• AI Tasks running low
• Publish succeeded or failed
• Runner / workspace stability events

Channels: Email (always available), Slack, Discord, Telegram. Each notification type can be toggled per channel.

What's not exposed to project owners (yet)

The internal xaio-monitoring dashboard — ECS / RDS / Aurora / ElastiCache views, raw CloudWatch metrics, error funnels and support-ticket triage — is an admin-only tool used by the XAIO operators. End users see derived signals (your published app's health, your build status, your AI task balance) but not the underlying infrastructure metrics.