Skip to main content

Cloud

Cloud integrations connect AI Expedite to where your services run, so the Ship → Monitoring tab can show logs, metrics, error reports, uptime, alerts, and cost data without you bouncing between cloud consoles. Google Cloud Platform is the only cloud provider with a complete adapter today; Vercel, AWS, and Azure adapters are stubbed in the same multi-cloud abstraction and slot in as they ship.

📷 Screenshot: Cloud-integration row on Settings → Integrations + a per-repo Monitoring Settings panel.

Google Cloud Platform (GCP)​

The default monitoring provider — the only fully-implemented adapter today.

Connecting​

  • From the Monitoring tab — open a repo accordion, switch to its Settings panel, and walk through the GCP setup. The flow uses workload-identity federation (no long-lived service-account keys), so what you grant is a short-lived OIDC trust between your GCP project and the AI Expedite identity pool.
  • From Settings → Integrations — the GCP row exposes the same setup steps, plus the workspace-level GCP project selection that applies when a repo's panel hasn't picked one explicitly.

The setup walks you through:

  1. Identifying the GCP project(s) the workspace should observe.
  2. Granting the platform's identity pool the relevant read scopes (monitoring viewer, logging viewer, error-reporting viewer, billing viewer for cost data, alert-policy viewer, uptime-check viewer).
  3. Mapping each connected repo to a specific Cloud Run service (or other resource) so the per-repo panels know what to query.

What it powers​

Every panel on the Monitoring tab:

  • Overview — request volume, p95 latency, 5xx rate, CPU, memory, instance count.
  • Errors — unresolved exception groups from Cloud Error Reporting.
  • Logs — Cloud Logging entries filtered by severity.
  • Uptime — Cloud Monitoring uptime checks and SLA percentage.
  • Cost — per-service spend from your billing-export BigQuery dataset, with anomaly flagging.
  • Alerts — Cloud Monitoring alert policies and their firing state.

The batch-status chip on each repo accordion's header is also computed by the GCP adapter — it's what colors a repo green / warning / error at a glance.

Permissions​

The minimum scope set is read-only across the listed services. Optional alert-policy write scope lets agents draft new alert policies you can apply with a click. Optional error-resolve scope lets agents mark error groups resolved from the Errors panel without bouncing to the GCP console.

Vercel, AWS, Azure (planned)​

The monitoring-provider abstraction in the platform is multi-cloud by design — every panel speaks to a MonitoringProvider interface that the GCP adapter implements today. Adding Vercel, AWS, or Azure support is a single-file drop-in; the UI doesn't need to change.

Until those adapters ship, repos backed by those clouds will render the Monitoring panels as "coming soon" placeholders rather than errors. You can still connect a non-cloud monitoring source in the meantime — for example, pin a Sentry MCP server (see Agents → MCP) and have your incident-triage agent query that instead.

Per-repo provider selection​

Each repo has its own monitoring provider configured under that repo's accordion → Settings panel. A workspace with one frontend on Vercel and three backends on GCP will (when the Vercel adapter lands) render appropriate panels for each — no global "the workspace is on GCP" flag.

Until you connect a provider for a repo, that repo's accordion shows the not-configured status chip with a Configure link that drops you straight into the Settings panel.

Removing the connection​

Removing the GCP integration severs the OIDC trust and disables every Monitoring panel until you reconnect. Past data the platform pulled (resolved errors, historical metrics in our snapshots) stays attached to its execution-log entries; new data stops flowing.