Reviewing Uptime Checks

This page shows you how to do the following:

  • Review the status of your uptime checks.
  • Get a list of IP addresses used by uptime checks.

To create, update, and delete your uptime checks, see the Managing Uptime Checks page. You can have up to 100 uptime checks per Workspace.

Uptime check overview

Monitoring has an overview page that displays all your uptime checks, and detailed dashboards for individual checks.

To see the overview, go to Uptime Checks > Uptime Checks Overview:

Go to Uptime Checks Overview

For each uptime check, you can see the last check result from each location, as shown in the following screenshot:

Uptime checks monitor


To get the detailed status of a single uptime check, click on any of the checks in the overview or in the list in the Uptime Checks menu. The following is a sample dashboard:

Uptime check details

The Location results region shows the results of the uptime check in all the applicable regions. A green dot next to a region indicates the last run of the check in that region succeeded; a red dot indicates failure. Moving your mouse over the dot displays the latency of the last run as well as the HTTP response code if applicable.

The Check config region includes a description of the uptime check, including the Check ID. This ID is assigned when the uptime check is created. The value corresponds to the [UPTIME_CHECK_ID] value in API calls.


To retrieve your existing uptime check configurations, use projects.uptimeCheckConfigs.list.

In the API, uptime checks are identified by their [UPTIME_CHECK_ID], which is a respelling of the uptime check's display name. For example, the display name "my uptime check" might become the ID "my-uptime-check", or the mapping might be more complicated.

You assign the display name that you see in the Uptime Overview in the Stackdriver Monitoring console.

Uptime percentage

The Uptime value is a percentage calculated as (S/T)*100, where S is the number of successful check responses and T is the total number of check responses, from all locations.

For group checks, the values of S and T are summed across all current group members.

For example, over a 25 minute period, an uptime check with a one-minute period running from all regions would get 25 requests from each of 6 locations, for a total of 150 requests. If the dashboard reports an 83.3% uptime, that means 25 of 150 requests failed.

Getting uptime-check IP addresses

If you are checking a service that is behind a firewall, you can configure your service's firewall to accept traffic from the current set of IP addresses used for uptime checking. To get the IP addresses, use the following instructions:


  1. Go to the Uptime Checks page for your project.

  2. Click Download Source IPs .


  1. Call the uptimeCheckIps.list method of the Monitoring API.

  2. The method returns the following information for each IP address:

    • A more specific location within the region.
    • The IP address, not a range, in IPv4 or IPv6 format.


public static object ListUptimeCheckIps()
    var client = UptimeCheckServiceClient.Create();
    var ips = client.ListUptimeCheckIps(new ListUptimeCheckIpsRequest());
    foreach (UptimeCheckIp ip in ips)
        Console.WriteLine("{0,20} {1}", ip.IpAddress, ip.Location);
    return 0;


private static void listUptimeCheckIPs() throws IOException {
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    ListUptimeCheckIpsPagedResponse response =
    for (UptimeCheckIp config : response.iterateAll()) {
      System.out.println(config.getRegion() + " - " + config.getIpAddress());
  } catch (Exception e) {
    usage("Exception listing uptime IPs: " + e.toString());
    throw e;


// listIPs is an example of listing uptime check IPs.
func listIPs(w io.Writer) error {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return fmt.Errorf("NewUptimeCheckClient: %v", err)
	defer client.Close()
	req := &monitoringpb.ListUptimeCheckIpsRequest{}
	it := client.ListUptimeCheckIps(ctx, req)
	for {
		config, err := it.Next()
		if err == iterator.Done {
		if err != nil {
			return fmt.Errorf("ListUptimeCheckIps: %v", err)
		fmt.Fprintln(w, config)
	fmt.Fprintln(w, "Done listing uptime check IPs")
	return nil


// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

// List uptime check IPs
const [uptimeCheckIps] = await client.listUptimeCheckIps();
uptimeCheckIps.forEach(uptimeCheckIp => {


use Google\Cloud\Monitoring\V3\UptimeCheckServiceClient;

 * Example:
 * ```
 * list_uptime_check_ips($projectId);
 * ```
function list_uptime_check_ips($projectId)
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,

    $pages = $uptimeCheckClient->listUptimeCheckIps();

    foreach ($pages->iteratePages() as $page) {
        $ips = $page->getResponseObject()->getUptimeCheckIps();
        foreach ($ips as $ip) {
                'ip address: %s, region: %s, location: %s' . PHP_EOL,


def list_uptime_check_ips():
    client = monitoring_v3.UptimeCheckServiceClient()
    ips = client.list_uptime_check_ips()
        [(ip.region, ip.location, ip.ip_address) for ip in ips],
        ('region', 'location', 'ip_address')


def list_ips
  require "google/cloud/monitoring/v3"
  client =

  # Iterate over all results.
  client.list_uptime_check_ips.each do |element|
    puts "#{element.location} #{element.ip_address}"

Uptime checks can come from any of the IP addresses, but only one address from each geographic location is used for each time interval. The geographic locations are listed in the uptime checks dashboard, as shown in the previous section. You can also use free, web-based services to identify the registered locations of the IP addresses you downloaded.

The IP addresses used by uptime checking might change, but typically not more than once per quarter and not without an announcement.

Identifying uptime check traffic

You can identify requests from the uptime-check servers by the following information in your service's request logs:

  • ip: The ip field contains one of the addresses used by the uptime-check servers. See Getting IP addresses.
  • User-Agent: The User-Agent header value is always the following:


    Specifying a User-Agent custom header results in a form validation error and prevents the check configuration from being saved.

Was this page helpful? Let us know how we did:

Send feedback about...

Stackdriver Monitoring
Need help? Visit our support page.