Cloud infrastructure
Mendral + GCP
Cloud Run logs, monitoring alerts, and GKE state — pulled into the agent at the moment of failure.
Or book a 15-min demo and we'll wire GCP into a live investigation.
Mendral connects to your Google Cloud project so the agent can investigate Cloud Run revision logs, pull monitoring alerts, and check GKE workload state when CI deploys or production smokes go sideways. Instead of a human pivoting between Cloud Console tabs, the agent runs the queries you would have run, in the same investigation thread that opened when CI went red.
What the agent can investigate
The GCP skill adds these surfaces to every Mendral investigation that touches GCP.
Query logs across Cloud Run, GKE, Cloud Functions, App Engine, and any other resource emitting to Cloud Logging — by time range, severity, or arbitrary filter.
Read alert policy state, incident history, and metric data so the agent can test whether a CI failure correlates with a service-level regression.
Revision metadata, traffic splits, and recent error logs. Common path for diagnosing failed deploys and bad config rollouts.
Pod status, deployment events, container restart history, and workload manifests — enough to root-cause CrashLoopBackOff, ImagePullBackOff, and OOMKilled scenarios.
Build history and step logs for the build that produced the artifact under investigation. Useful when a runtime error traces back to a packaging bug.
Instance events and operation history when a deploy correlates with database state changes.
How it works
The agent gets a GCP skill that wraps the GCP SDK with read-only roles. Each workspace can authorize service accounts in multiple projects, and every API call the agent makes is logged with the investigation ID. Investigations can be triggered by CI, by webhooks from connected services, or by the agent itself when an upstream investigation needs GCP context.
Connect via a GCP service account with read-only viewer roles (logging.viewer, monitoring.viewer, run.viewer, container.viewer). Multi-project setups can register multiple service accounts under one workspace.
Example investigation
After a Cloud Run deploy, the smoke test in CI starts returning 500s. The CI step fails.
- 1
Identifies the affected Cloud Run service from the deploy script.
- 2
Pulls the most recent revision's logs filtered to severity ≥ ERROR.
- 3
Sees: Container failed to start: missing env var DATABASE_URL.
- 4
Diffs the new revision's config against the previous green revision.
- 5
Notices the DATABASE_URL secret was renamed in a Secret Manager rotation 12 hours earlier.
- 6
Opens a PR updating the deploy YAML to reference the new secret name, with the rotation log attached.
Five-minute fix instead of a 30-minute incident bridge.
Frequently asked
What permissions does the service account need?
Read-only viewer roles for the GCP products you want investigated — typically logging.viewer, monitoring.viewer, run.viewer, and container.viewer. We publish a sample IAM policy you can copy.
Can Mendral cover multiple GCP projects?
Yes. Each workspace can authorize service accounts in any number of projects. The agent picks the right one based on which service it's investigating.
Does the agent run gcloud commands directly?
It uses the GCP SDK via a sandboxed skill. Calls go through the API with the service account's permissions — no gcloud CLI is installed in the runtime.
How are GCP API calls audited?
Every call the agent makes during an investigation is logged with the investigation ID and is visible in your workspace audit log. Cloud Audit Logs in your project also record the calls under the service account identity.
Put GCP context
in every investigation.
Five-minute install. GCP connects from the workspace settings. First enriched investigation runs on the next CI failure.
Or book a 15-min demo with the founders.