Monitoring

Workspace logs, published-app errors and notification channels.

What's monitored

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

• Workspace backend while iterating in dev
• Preview & build errors caught in the browser and at build time
• 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 *.airbuild.space (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
• Storage usage — every project has a storage quota; you see your current usage in Project Settings
• Log stream — the Monitoring view under Deployments shows your published backend's CloudWatch lines for a chosen window (1 hour to 7 days, or a custom range), with text search and error/warning classification. Request counts and latency are not exposed to project owners yet

Notifications: getting pinged about events

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

• Code generation completed / failed
• Organization or workspace invite
• New member joined
• AI Tasks running low
• Publish succeeded or failed

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

What's not exposed to project owners (yet)

Airbuild runs its own operations monitoring — platform infrastructure metrics, fleet-wide error funnels and support triage — as an internal admin tool, not as part of the product. As a project owner you see the derived signals: your published app's health, your build status, your log stream and your AI task balance, not the platform metrics underneath.