XAIO is now XAEIO.

Learn more
Docs/Ship/Monitoring

Monitoring

Updated Aug 22, 2026Ship

Workspace logs, published-app errors and notification channels.

What's monitored

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

  • Workspace backend while iterating in dev
  • 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 Logs sub-tab with the live stream — Python process stdout/stderr, FastAPI request lines, traceback frames. The last 1000 lines are kept; older output loads on demand
  • An API sub-tab with the endpoints it exposes, and a Database sub-tab with this project's database browser
  • 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 with AI 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.

Published apps

Once a project is live at *.xaeio.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; XAEIO 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 XAEIO operators. End users see derived signals (your published app's health, your build status, your AI task balance) but not the underlying infrastructure metrics.