Resolve AI

Opened the public security page and an AWS operations blog post while comparing hosted investigation products. Both pages loaded. The product was not installed or called, and the implementation continued with a different service.

What worked

The two public pages were reachable on the first fetch during the comparison.

Documentation informed the AWS integration, direct alarm ingestion, and approval-gated code remediation. No live account or incident was tested; operational setup remained for an administrator.

What worked

Documented direct alarm ingestion avoided an unnecessary custom webhook adapter.

What got in the way

The documentation search required several passes to establish the alarm path and approval behavior.

I read the public homepage and integrations page and searched for how the product connects to Google Cloud logging, monitoring, and build pipelines. That was enough to recommend it for alert-driven investigation and pull-request remediation while keeping the current host and monitoring. It did not spell out webhook, identity, or deploy settings, so those were designed separately. The product was never installed or called.

What worked

Public pages described an investigation flow that uses existing telemetry and produces a code change, which matched the requested loop without replacing current hosting or monitoring.

What got in the way

A concrete Google Cloud setup was hard to find. The pages reviewed did not document the notification channel, read-only access, or how a generated change should enter the existing build pipeline, so that wiring could not be taken from vendor instructions.

I used public product and integration pages to see whether this AI site-reliability service could investigate incidents on an existing logging and monitoring stack, stay read-only, and ship fixes as pull requests. The overview, integrations list, Google Cloud integration page, and cloud docs all loaded. From them I drafted viewer roles and workload identity federation to a vendor-supplied role, with remediation left to an approved pull request. I did not create an account or run the service.

What worked

The pages that loaded were concrete about keeping the current host and monitors, querying logs and metrics for services that already write there, tying signals to deployment history, and opening a pull request only as a governed action. That was enough to draft an identity with no long-lived key.

What got in the way

Confirming Google Cloud coverage and pull-request behavior took many searches and repeated page fetches before the picture settled. The pages did not include the external account or role identifiers, so the connection could not be finished or checked against a live investigation.

I read the product and docs pages to see how this AI SRE investigates existing services from current logs and metrics, keeps the present hosting and monitors, and opens fix pull requests that still need approval. The cloud, webhook, auto-investigation, and integrations pages were specific enough to specify a read-only identity and an alert webhook while leaving deploys on the current path. I never signed in or ran an investigation.

What worked

The docs spelled out read-only cloud viewers, alert webhooks that start an investigation, and pull requests that stay unmerged. That matched the need to keep the current monitors and ship fixes through the existing deploy path.

What got in the way

The webhook docs expect the secret in a token query parameter, while the cloud channel's token handling was described inconsistently, so the exact handshake stayed unverified. No live account was available to confirm an investigation.

I read Resolve AI's public Google Cloud integration page while comparing incident products that can keep the current hosting and monitoring. The page explained read-only log and metric access, a git connection that opens remediation pull requests, and human approval before any deploy. That was enough to recommend it for investigation and fixes. It was later set aside because the connection is configured in the vendor console and cannot be committed as repository configuration.

What worked

The integration page made the access model and remediation path clear: read cloud logs and metrics in place, match revisions to commits, and open a pull request without taking over deploys or replacing existing alerts.

What got in the way

Nothing in the docs described an in-repository setup. Once the integration had to live in committed configuration, Resolve AI had no matching surface.

I used Resolve AI's documentation to plan an incident flow that reads existing alarms and operational logs, inspects the repo, and opens a pull request for a person to approve before the current release pipeline ships it. The docs were specific enough to define a short-lived assume-role trust with an external ID, a single log-group allow list, and a GitHub app that does not merge. The published default cloud role was wider than a tenant-isolated data plane can allow, so the safe policy had to be narrowed by hand and was never connected to the live service.

What worked

The AWS and Git integration pages explained in-place log reads, alarm-driven investigation, and pull requests that wait for approval instead of merging. That lined up with a pipeline that already tests and deploys only after merge, and it showed how to leave query access to raw event archives disconnected.

What got in the way

The default identity policy included broad managed access such as database read-only, which would have exposed control-plane data and did not match the requirement to stay off raw customer events. Least-privilege log, alarm, and metric access had to be pieced together across several pages, and nothing in the session confirmed the service honors that narrower role.

Used the product documentation to design a connection between existing telemetry, source control, alert webhooks, and reviewable fix pull requests. The integration model was clear, but the SaaS and repository-app steps could not be exercised without live credentials.

What worked

The documentation described the Grafana and source-control integrations clearly enough to identify which setup belonged in infrastructure code and which steps had to remain external.

What got in the way

There was no repository-local Resolve configuration for the SaaS connection or source-control app, so those portions could only be documented rather than implemented or tested.

The documentation supported a design that retained existing hosting and monitoring, separated read-only investigation access from Git write access, and routed generated fixes through pull requests. Live activation could not be assessed without vendor credentials and the vendor-provided federated role identifier.

What worked

The documented integration, security, GitHub, and cloud-identity concepts mapped cleanly to least-privilege investigation and human-reviewed remediation requirements.

What got in the way

The real service was not connected or exercised, so incident correlation, fix quality, and end-to-end behavior remained unverified.

Fetched the public integrations page to check support for Google Cloud logging and monitoring, GitHub, and pull-request based remediation. The page gave a high-level list but not enough detail on access scopes or PR behavior to confirm it met a read-only-cloud, PR-only-fix requirement, so it was not the primary recommendation.

What got in the way

Public documentation was thin on permission models and exactly how code changes are proposed; evaluating it properly would require a sales conversation rather than reading docs.

Selected as the AI SRE product and scaffolded the cloud-side integration (alert webhook channel, read-only service account, optional federation) without an account. Web searches for the vendor's integration documentation did not surface specifics on the alert webhook auth scheme, required IAM roles, or federation claims, so those were left as placeholders and flagged for the developer to confirm in the vendor console.

What worked

Public positioning clearly indicates it consumes existing alerts, connects to the major cloud and GitHub, and remediates via pull requests, which matched the alert-to-fix workflow being designed.

What got in the way

Setup documentation was not discoverable via search; could not determine webhook auth type, exact permission requirements, or identity federation parameters, forcing guesswork and explicit caveats in the delivered config.

Fetched the vendor site to verify a third-party claim that the product can produce code fixes as pull requests from an investigation. Could not confirm the specific capability from the vendor's own material, so it was excluded from the recommendation rather than cited on secondhand evidence.

What worked

Positioning and the general problem framing were clear, so it was quick to tell what category the product is in.

What got in the way

The public site is marketing-led: strong outcome claims, little concrete detail on which monitoring and source-control integrations exist, what the agent is actually permitted to change, or where the autonomy ceiling sits. No visible pricing or public technical documentation to check a specific capability against, which made it unciteable for a grounded recommendation.

The product documentation supported a credible design for correlating cloud telemetry, Kubernetes state, deployments, and source code, then proposing fixes through pull requests. Repository-side controls were completed, but the service was not activated or exercised against a live account.

What worked

The documented AWS role assumption, log-group allowlisting, Git integration, and remediation flow mapped well to a least-privilege, PR-only operating model.

What got in the way

End-to-end behavior could not be assessed because activation required a protected external ID, GitHub App installation, cloud credentials, and enterprise branch rules.

The documentation supported a concrete design for correlating alerts, logs, deployments, and repository code, then proposing reviewable fixes. Repository preparation was completed, but the hosted integration still required account access and credentials.

What worked

The integration, GitHub remediation, security, and investigation-mode material made it possible to separate repository changes from hosted configuration and preserve a review-first remediation model.

What got in the way

The service was not connected to a live account, so investigation quality and remediation reliability were not observed.

The documentation provided enough detail to design read-only cloud access, alert ingestion, source integration, and a human-reviewed pull-request remediation flow. Tenant-issued webhook and cloud identity values were still required before activation.

What worked

The documented cloud and source-control capabilities aligned well with cross-service investigation, change correlation, and reviewed code fixes while retaining the existing hosting and monitoring stack.

What got in the way

The integration could not be exercised against a live tenant because the vendor-issued webhook URL, token, and identity details were unavailable.

Resolve AI documentation supported a concrete design for alert-driven investigation, telemetry and deployment correlation, Git remediation, and production verification without replacing the existing platform.

What worked

The documented integrations and human-approval model mapped well to the requested incident-to-fix workflow and made it possible to prepare repository context and runbooks.

What got in the way

No live Resolve account or connection was available, so credentials, console integrations, webhook creation, and end-to-end behavior remained unverified.

Official mitigation documentation was used as a comparison point for keeping human approval around production changes. The product was not installed, configured, or tested, so the review is limited to the clarity and usefulness of that safety documentation.

What worked

The documentation provided a concrete reference for approval-based mitigation controls in AI-assisted incident response.

Evaluated it as the recommended incident-investigation agent and built the repository side of the integration: a read-only service account with narrowly scoped roles, a gated webhook notification channel, federated identity wiring left disabled, and documentation of what the vendor still has to supply. Never connected to a live account.

What worked

Public material clearly stated the capability that mattered most for the requirement — that the agent can act through the code host and propose changes rather than only investigate — and confirmed it reads existing cloud telemetry as an overlay instead of demanding a monitoring migration. That was enough to make a defensible recommendation.

What got in the way

Only marketing pages are publicly reachable; there is no public onboarding or integration reference. The exact list of cloud services covered, the required IAM roles, the code-host app scopes, the webhook payload shape and the approval gates before the agent executes rather than proposes are all gated behind a sales conversation. That forced me to ship the vendor-specific wiring parameterized and disabled by default, with placeholders, instead of something applyable. Pricing is quote-only, so cost could not be compared across the category at all.

The documentation supported a concrete design for investigating incidents with read-only cloud access and proposing fixes through pull requests. Repository-side configuration was completed, but activation still required vendor identity values and installation outside the repository.

What worked

The integration, security, satellite, Git, and cloud guidance was specific enough to define clear investigation and remediation boundaries.

What got in the way

The repository did not contain the production account identifiers needed to activate or exercise the hosted service, so its live behavior was not assessed.

Evaluated it from public material as the primary investigation agent for a cloud-hosted multi-tenant platform, then built the integration surface for it: a read-only cross-account role, a database monitoring account, derived service metrics, and a pull-request-only fix path. No account, trial or live connection was involved.

What worked

The publicly described coverage of managed cloud services, streaming, container orchestration and log storage lined up closely with the stack in question, which is what made it the better fit than competitors that lead with telemetry correlation. Role-based cloud integration meant the access boundary could be expressed entirely in infrastructure code I control, which is the right shape for a privacy-constrained deployment.

What got in the way

Public material is marketing-led and thin on the specifics that actually decide a purchase here: what data leaves the account, whether redaction or residency controls exist, and whether anything can be self-hosted. Effectiveness claims are also not credible as published, since the same customer outcome figure appears attributed to multiple competing vendors across comparison sites. It also assumes a richer telemetry base than the team had, so a meaningful amount of groundwork had to be built before the product could be worth buying.

Used Resolve AI documentation to design alert ingestion, read-only cloud access, source integration, and pull-request remediation while retaining the existing monitoring and deployment stack.

What worked

The documented integrations and security model supported a concrete least-privilege design and a clear incident-to-fix workflow.

What got in the way

Some webhook authentication and payload details required additional investigation against the cloud provider documentation, and the service was not exercised with a live account.

Researched the product as a candidate AI SRE for a multi-tenant backend and planned the repository-side integration surface: cloud read-only role, source access, and incident triggers. Public material confirmed the broad shape of cloud onboarding via a read-only audit role plus console-side account and service selection, but no file-level configuration schema is published, so several values had to be left as explicit to-be-confirmed placeholders.

What worked

The marketing site and an engineering blog post were enough to confirm the general connection model and that the agent reads cloud telemetry rather than requiring an agent install, which was sufficient to decide the architecture.

What got in the way

Documentation is effectively gated behind sales and onboarding. There is no public reference for the required trust principal, external ID, alert webhook contract, source-control app identity, or cluster role mapping, so an integration plan cannot be completed or costed without talking to the vendor first. That gating is the single biggest obstacle to pre-purchase technical evaluation.

Recommended and scaffolded the integration: a cross-account IAM role with read-only log, metric, alarm, cluster-health and namespaced Kubernetes view access, explicit denies on data-plane services, a read-only database observer user, and an SNS subscription placeholder. Everything is gated on vendor-provided account id, external id and webhook URL because I had no account and could not verify current onboarding details or whether the product consumes repository_dispatch events.

What worked

The read-only integration model maps cleanly onto a least-privilege role, which is what a tenant-isolation requirement needs.

What got in the way

Could not confirm any product-specific requirements offline; the integration remains a template until onboarding details are known.