What does the bot measure?

An uptime check records whether a configured endpoint succeeds, along with response timing and any configured content validation. The results can drive metrics and alerts.

Does it affect AI search or model training?

No. This is operational monitoring traffic. It does not index pages for search, supply citations, or collect a documented model-training dataset.

Does GoogleStackdriverMonitoringBot respect robots.txt?

Yes, according to this bot. The stable token is `GoogleStackdriverMonitoringBot`. Because an uptime check targets a configured endpoint and Google's current documentation uses another user-agent value, changing the monitoring configuration is usually a more reliable control.

How can I identify current Google Cloud uptime checks?

Google currently documents the fixed user agent `GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)` and publishes a live list of checker IP addresses. Use both the current documentation and your Cloud project configuration; the header alone can be spoofed.

Should I block the monitoring bot?

Do not block a check your team relies on, since failed probes can trigger outage alerts. If the traffic is obsolete or unauthorized, remove the uptime configuration or enforce access at the monitored endpoint.

GoogleStackdriverMonitoringBot Bot Guide

What is GoogleStackdriverMonitoringBot?

GoogleStackdriverMonitoringBot is associated with Google Cloud uptime checking. It sends a probe to an endpoint selected in a Cloud Monitoring configuration so the service owner can tell whether that endpoint is available and responding as expected.

Google Cloud supports public checks from multiple geographic locations and private checks for internal Google Cloud resources. Depending on the configuration, an uptime check can query an HTTP, HTTPS, or TCP endpoint and validate returned data.

Each checker request is stateless. Google Cloud records success or failure along with timing information, exposes the results as uptime-check metrics, and can feed failures into an alerting policy. Repeated requests to the same health URL are therefore normal monitoring traffic, not an attempt to enumerate a site.

The bot does not build a search index and does not follow pages to discover content for answers. It has no direct AI search, citation, or model-training function. A monitoring visit says something about an uptime configuration, not about how an AI system uses the page.

Identity needs care because the stored token and Google's current documentation differ. this bot retains GoogleStackdriverMonitoringBot, while Google Cloud's uptime-check documentation publishes GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring) as the current fixed user agent. Check the exact value present in your logs before writing a filter.

Google also publishes the current uptime-check server addresses through the Cloud console, CLI, and Monitoring API. This bot is marked unverifiable and has no Cloudflare directory details, so a user-agent match alone should not grant access. Compare the source with Google's current list and trace the check back to a Google Cloud project when possible.

The record marks GoogleStackdriverMonitoringBot as following robots.txt and supplies a stable token. Even so, robots policy is an awkward way to manage a configured health probe. Removing or changing the uptime check is clearer, and blocking an expected probe can create a false outage signal.

Not relevant for AI search

Is GoogleStackdriverMonitoringBot relevant for AI search?

No. GoogleStackdriverMonitoringBot is not part of AI search or training, so allowing or blocking it does not change your AI visibility.

GoogleStackdriverMonitoringBot runs synthetic monitoring or uptime checks on a schedule. It is not collecting content for any index or model, so it has no bearing on search rankings or AI answers. You usually see it because your own team or a service you use set up a check.

How to handle GoogleStackdriverMonitoringBot

Allow requests that belong to an uptime check your organization expects. If a firewall protects the endpoint, use Google's current published checker addresses and keep the health route limited to the minimum access it needs.

The stored bot token supports this robots.txt rule:

User-agent: GoogleStackdriverMonitoringBot
Disallow: /

Before relying on it, compare the request with current Google documentation because modern uptime checks publish a different fixed user-agent value. A robots block can also cause the check to fail, so disable or edit the Cloud Monitoring configuration when the probe itself is no longer wanted.

For unexpected traffic, search the relevant Google Cloud projects for an uptime-check configuration and compare the source IP with Google's live checker list. Do not allow the request solely because its header contains a Google-looking name.

Examples

An SRE recognizes repeated requests to `/healthz` as a configured public uptime check and excludes them from visitor analytics.
A firewall change starts returning errors to Google Cloud checkers, so the operations team restores access to the health endpoint before treating the alert as an application outage.
A security team finds monitoring traffic nobody recognizes, checks the source against Google's current checker list, and searches its Cloud projects for the matching configuration.

Frequently asked questions about GoogleStackdriverMonitoringBot

Learn about AI visibility monitoring and how Promptwatch helps your brand succeed in AI search.

Google Cloud operates the uptime-check infrastructure. Individual Google Cloud customers configure the endpoint, regions, and response conditions for their checks.