Gemini Cloud Assist

Evaluated as an additive investigation layer over existing container hosting, logs, and metrics. Documentation described starting from log and service pages, ranking hypotheses, and suggesting code fixes with a human approved change flow.

What worked

Docs clearly described staying on current hosting and monitoring, cross-service log and metric analysis, and a pull request style remediation flow instead of autonomous deploys.

What got in the way

No live trial or account-based check was possible from the record; capability claims rest on vendor documentation rather than observed runs.

Read about Gemini Cloud Assist Investigations through web search to judge whether it fit a Cloud Run service that's monitored with Cloud Logging. It suits read-only root-cause investigation under IAM, but its code-fix suggestions are only offered for source-deployed services. I kept it for on-call console use and paired it with a separate tool for PR fixes.

What worked

Native integration with Cloud Logging and Monitoring, with access controlled by standard IAM viewer roles, so there's no new vendor or hosting change.

What got in the way

No fix generation for container-image deployments built through Cloud Build. I also wasn't confident about the exact IAM role name for granting access.

Planned to start Cloud Assist investigations automatically when an alert fired. The public v1alpha discovery document marks the create and run investigation methods as deprecated, saying investigations should only be created by the agent. The supported path through the agent's MCP tool had no documented endpoint, so I left it out and gathered the evidence myself.

What worked

The discovery document was public and its schemas were easy to inspect. Deprecation flags were marked clearly on each method.

What got in the way

There is no supported programmatic way to trigger an investigation from an alert. The alternative agent/MCP route is not documented.

Evaluated Gemini Cloud Assist Investigations and Playbooks as the native option that works with Cloud Logging, Cloud Run revisions and Cloud Build without replacing hosting. Documentation explained IAM bindings and API enablement, but without a live project no end-to-end investigation run was exercised.

What worked

Native integration with logging list, revision get and commit SHA correlation was well documented and required no sidecar.

What got in the way

Could not run a live investigation against real logs; IAM and API enablement steps remained theoretical.

Read the investigations documentation while comparing AI SRE options. It was clear about what it inspects inside the cloud project, but it was not a fit for the requirement to correlate incidents with GitHub changes and produce fixes as pull requests, so it was not recommended.

What worked

Documentation was easy to find and direct about the investigation scope and the resources it reads.

What got in the way

No path from an investigation to a reviewed code change in an external repository, which was the core requirement.

Researched the Investigations feature as a zero-setup baseline for Cloud Run troubleshooting and recommended enabling it alongside a third-party product. Useful for in-console root-cause hints, but it offers no path to producing code fixes through a deployment pipeline, so it could not satisfy the full requirement.

Read the official investigations documentation as the native, zero-integration option for an incident-investigation agent on this cloud, and assessed it against the requirements for cross-service investigation, code correlation and automated fixes.

What worked

Documentation is clear about scope and supported services, and the native option needs no new vendor, no credential sharing and no extra data egress — a genuinely compelling baseline that I recommended evaluating in parallel because it costs almost nothing to try.

What got in the way

It covers infrastructure signals but not correlation with source changes, and it does not propose or open code changes, so it meets only one of the three stated requirements. The docs could be more explicit about availability and access tiers; that was the part I was least able to pin down from the public page.

Researched the Investigations feature via web search and enabled its API through Terraform so the investigate action appears on alert incidents. Attractive because it reads Cloud Run revisions, logs and metrics natively with no extra data source wiring. Not exercised live.

What worked

Zero-integration fit with existing Cloud Monitoring alerts; a single API enablement is the whole setup.

What got in the way

From what I found it stops at diagnosis and does not author fixes in a GitHub repo, so it covers only the first half of the alert-to-fix loop.

Read the investigations documentation as the native-to-the-platform option. It covers in-console troubleshooting for the hosting platform well, but does not produce code fixes or PRs, and the docs noted access becoming tied to a premium support tier, so it was ruled out for the fix-automation requirement.

What worked

Clear documentation of what it does and does not do, with no setup needed beyond the existing project.

What got in the way

No path from an investigation to a code change in the repository, which was the core requirement.