Google Home Vitals (Cloud)

This suite of dashboards and alerts helps you proactively maintain a high-quality integration with the Google Home ecosystem. Google is committed to supporting partners in developing a high quality ecosystem for all customers

The dashboard has three sections, each covering a key part which contributes to the quality of an overall integration.

1. Google to Partner Metrics - Measures the health of calls from Google to your cloud backend.

2. System Health - Partner to Google Metrics - Measures the health of calls from your system to Google.

3. Device Health - State Accuracy - Measures the accuracy of states stored in Google systems, which are used to serve user queries.

When metrics don't meet their target values, they are highlighted in red to indicate an issue that could impact the user experience. The following information provides details on each target and why it matters to your users.

If the following button doesn't take you directly to the dashboard, you can get to it by selecting the Overview page, select Dashboards and then from the My Dashboards list select Google Home Vitals Dashboard (Cloud) to view your dashboard.

Go to Dashboard

Google to Partner metrics

The Query/Execute Success Rate >= 99.5% metric measures how often users' commands are fulfilled correctly, which helps avoid Assistant responses such as "I can't reach the device" or incorrectly confirming a command that wasn't fulfilled.

What defines a "Success"?

A transaction is marked as a success if the Google Home platform receives a valid response indicating the intended action was fulfilled or the requested state was retrieved.

Responses that include non-blocking exceptions (for example, a SUCCESS status accompanied by a lowBattery exception) are counted as successful transactions. The command reached the device and the intent was satisfied despite the warning.

What defines a "Failure"?

The errors found on Common platform error codes which are marked as Partner Actionable are considered "Failures" when calculating the QUERY and EXECUTE Success Rates. Additionally, the errors found on Errors and exeptions are also "Failures", with the following exceptions:

The Query/Execute Latency (p90) <= 1000ms metric measures requested action wait time and helps ensure users don't have to wait too long, for example, waiting a few seconds for their light to turn off.

Latency metrics

Latency is a critical indicator of how responsive your integration feels to the end-user. The dashboard tracks the 90th Percentile (P90) Latency, which represents the experience of your "slowest" users (for example, a P90 of 800ms means 90% of requests are acknowledged in 800ms or less).

Google measures latency differently for status checks versus device commands to ensure technical accuracy.

1. QUERY Latency (Interrogative)

This measures the Cloud-to-cloud round trip time when Google asks for the current state of a device.

• Start: Google dispatches an action.devices.QUERY request to your fulfillment URL.
• Measurement Window: The time taken for your cloud to receive, process, and transmit the full HTTP response back to Google.
• End: Google receives and acknowledges the final response payload from your service.

2. EXECUTE Latency (Action)

This measures the command acknowledgment time when Google sends a control request to a device.

• Start: Google dispatches an action.devices.EXECUTE request to your fulfillment URL.
• Measurement Window: The time taken for your cloud to receive the command and return an acknowledgment response.
• End: Google receives the SUCCESS, PENDING, or OFFLINE status response.
• Technical Scope: This metric measures the "Response Ack" time between Google's cloud and your cloud. It does not measure the time it takes for the physical hardware (for example, a lightbulb) to complete the physical state change, as that often involves local mesh network latency outside of the cloud-to-cloud path.

Latency reduction options

Architectural recommendations for geo-routing

If Anycast IP implementation is not feasible, we recommend the following cost-effective alternatives to ensure users are served by the closest regional data center.

1. Global Load Balancing (GLB)

   Instead of static routing, use a Global Application Load Balancer (available from most major cloud providers).

   • How it works: You configure a single global entry point (URL) that sits at the network edge. The load balancer automatically detects the geographic origin of the request from Google's fulfillment clusters and routes the traffic to your nearest regional healthy backend.

   • Benefit: This provides the performance of Anycast with significantly lower configuration complexity and cost.

2. Geo-Location Aware DNS (GeoDNS)

   • How it works: Configure your DNS provider to resolve your fulfillment URL to different IP addresses based on the geographic location of the DNS query.

   • Implementation: Ensure your DNS provider is optimized for Google's egress points. When Google's regional fulfillment services (for example, in the US, EU, or Asia) resolve your domain, they will receive the IP address for the data center in that specific region.

Optimization strategies at the application layer

Beyond infrastructure-level routing, you can implement the following strategies at the application layer to reduce latency in request processing.

1. The "Trampoline" Proxy Method

   If you must maintain a primary data center, use regional lightweight proxy servers (Trampolines) to handle the initial handshake.

   1. Google hits your global URL.

   2. A regional proxy (for example, a lightweight Nginx or Lambda function) receives the request.

   3. The proxy forwards the payload over your internal, high-speed backbone to the primary database.

   Benefit: This reduces the "TCP Handshake" time, which is often the largest contributor to latency for long-distance requests.

2. Access Token Region Hints

   During the Account Linking (OAuth) process, your system can identify the user's home region.

   Implementation: Encode a region identifier into the access_token issued to Google. When Google sends a fulfillment request, your gateway can immediately inspect the token and route the request to the correct regional cluster without needing a database lookup.

System Health - Partner to Google metrics

Maintaining a Success Rate >= 99.5% helps ensure that device states are correct in Google Home, devices are added and removed, automations trigger, and history events appear in the Google Home app (GHA)'s Activity tab.

The Success Rate is calculated based on the HTTP response codes returned by Google when your cloud pushes state updates. To ensure partners are not penalized for Google-side infrastructure issues, the metric excludes Google internal errors from the failure count. The API calls included in the calculation are found in the HomeGraph API reference.

What defines a "Success"?

2xx (Success): The state update was successfully received and processed by Home Graph.

What defines a "Failure"?

4xx (Partner Error) represent failures and indicate an issue with the request sent from your cloud. Common codes include:

400 Bad Request

Cause: The server was unable to process the request due to invalid syntax. Common causes include malformed JSON or using null instead of "" for a string value.

Solution: Ensure the request body is valid JSON (no malformed structure or null values for string fields), and verify that agentUserId matches the value from the SYNC response.

404 Not Found

Cause: deviceId or agentUserId not found in HomeGraph (not synced yet, already unlinked, or ID mismatch).

Solution:

1. Ensure that the agentUserId matches the value provided in your SYNC response.
2. Use the Home Graph SYNC API to determine whether the 404 Not Found error is caused by a missing device or user in HomeGraph.
3. Make sure to trigger requestSync after device or account add, remove, rename, or update to ensure the state stays up to date.
4. Properly handle DISCONNECT intents to stop reporting stale devices. After receiving the DISCONNECT intent, your cloud service should cease publishing changes to Google with Request Sync and Report State.

429 Resource Exhausted

Cause: Your integration has exceeded its allotted quota.

Solution: See the instructions in the "Step 2a: Debug Quota Issues" section in the dashboard for quota management. You can also refer to Smart Home quotas and limits for more information.

Device Health - State accuracy

Meeting or exceeding a State Accuracy >= 99.5% helps ensure users see correct results when they view device states or use AI features like Ask Home. If state accuracy is low, automations may not fire and history entries may not appear in the GHA's Activity tab at the right time. For more information, see Report State.

The quality dashboard tracks this hourly using two distinct metrics: Overall Accuracy and the Lowest Type/Trait Combo.

1. Accuracy Components

The metric is derived from "samples" where Google can verify the reported state against a known intent outcome.

2. Dashboard Metrics (Hourly Calculation)

The dashboard calculates accuracy based on a 1-hour interval. If an hour has fewer than 100 total samples (S_Total < 100), the accuracy for that hour is set to N/A.

View 1: Overall Accuracy (Global Average)

This represents the total accuracy of your integration across all device types and traits combined. It provides a weighted average of your entire ecosystem's health.

• Calculation: Total State Accuracy across all devices / Total State Total across all devices.

View 2: Lowest Type/Trait Combo

This identifies the most unreliable specific category in your integration. It prevents high-volume devices which are at high-quality from hiding low-volume devices which are at low quality. For example, if you have a high volume of lights above 99.5% State Accuracy, but a low volume of Switches at a low State Accuracy, this highlights the improvement needed on switches that may be lost in an average value.

• Calculation: Minimum of State Accuracy / State Total for all trait/device combinations.

3. Improving Device Health & State Accuracy

Discrepancies occur when the state stored in the Home Graph does not match the results of a real time QUERY.

"Missing Field" errors

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD"
    deviceId: "curtain"
    deviceType: "action.devices.types.CURTAIN"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-13T12:20:26Z"
    queryReportStateDifferences: {
      queryState: "open_close    {
        open_percent: 0.0
        missing open_direction
      }"
      reportState: "open_close   {
        open_state {
          open_percent: 100.0
          open_direction: "LEFT"
        }
      }"
    }
    reportedTime: "2022-05-13T07:14:35Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T12:20:26Z"
    stateName: "open_state"
    traitName: "TRAIT_OPEN_CLOSE"
  }
  

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD"
    deviceId: "sensor"
    deviceType: "action.devices.types.SENSOR"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-28T10:40:33Z"
    queryReportStateDifferences: {
      queryState: "temperature_setting {
         thermostat_mode: "off"
         thermostat_temperature_ambient: 20.0
         active_thermostat_mode: "none"
      }"
      reportState: "temperature_setting {
         thermostat_mode: "off"
         active_thermostat_mode: "none"
      }"
    }
    reportedTime: "2024-09-20T15:00:00Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-28T10:40:33Z"
    stateName: "thermostat_temperature_ambient"
    traitName: "TRAIT_TEMPERATURE_SETTING"
  }
  

Cause: With the DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD or the DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD error, the set of payload fields differs between your QUERY response and your Report State request for the same device.

Solution: Ensure the data structure is identical in both pathways. If a trait is included in SYNC, its corresponding fields must be present and consistent in both proactive reports and reactive queries.

"Inaccurate" errors

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_INACCURATE"
    deviceId: "outlet"
    deviceType: "action.devices.types.OUTLET"
    isMissingField: false
    isOffline: false
    queriedTime: "2026-04-12T16:02:58Z"
    queryReportStateDifferences: {
      queryState: "on_off    {
        on: false
      }"
      reportState: "on_off   {
        on: true
      }"
    }
    reportedTime: "2025-03-10T01:56:44Z"
    requestId: "abc"
    result: "INACCURATE"
    snapshotTime: "2026-04-12T16:02:58Z"
    stateName: "on"
    traitName: "TRAIT_ON_OFF"
  }
  

Cause: For the DETAILED_ACCURACY_RESULT_INACCURATE error, there is a discrepancy between the value returned in the QUERY response and the last Report State value.

Solution: Ensure Report State is triggered whenever a device status changes and that both Report State and QUERY always provide the exact same, up-to-date values and all required fields to maintain data consistency.

"reportStateLog": {
   "isMissingField": false,
   "snapshotTime": "2026-04-13T07:56:21Z",
   "traitName": "TRAIT_ON_OFF",
   "detailedAccuracyResult": "DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE",
   "executionReportStateDifferences": {
      "expectedPostExecutionDeviceState": {
         "onOff": {
         "on": false
         }
      },
      "preExecutionDeviceState": {
         "onOff": {
         "on": true
         }
      },
      "executionCommand": {
         "requestId": "test001",
         "beginTimestamp": "2026-04-13T07:56:20Z",
         "action": {
         "trait": "TRAIT_ON_OFF",
         "actionType": "ONOFF_OFF"
         },
         "status": {
         "statusType": "SUCCESS_STATUS"
         },
         "endTimestamp": "2026-04-13T07:56:21Z",
         "executionType": "PARTNER_CLOUD"
      },
      "reportState": {}
   },
   "accuracy": "MISSING_REPORT_STATE",
   "deviceType": "action.devices.types.LIGHT",
   "agentId": "abc",
   "stateName": "on",
   "result": "MISSING_REPORT_STATE"
   }
  

Cause: With the DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE error, the partner executed the command successfully, but did not report the updated device state back to Google.

Solution: Always send a Report State update after command execution so Home Graph receives the new device state.

eportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED"
    deviceId: "switch"
    deviceType: "action.devices.types.SWITCH"
    isMissingField: false
    isOffline: true
    queriedTime: "2026-04-13T13:53:26Z"
    queryReportStateDifferences: {
      queryState: "online    {
        online: false
      }
      "
      reportState: ""
    }
    reportedTime: "1970-01-01T00:00:00Z"
    requestId: "test001"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T13:53:26Z"
    stateName: "online"
    traitName: "TRAIT_ONLINE"
   }
  

Cause: For the DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED error, no Report State has been received for this device (the state is empty and the reported timestamp is at epoch), despite the QUERY results providing the current status. This indicates that state updates are either not being triggered, are failing to reach HomeGraph, or the device is not successfully reporting transitions in its connectivity or operational status.

Solution: Ensure Report State is triggered and successfully sent for all state changes. Verify that the backend logic correctly handles status updates, confirms delivery success to the Google HomeGraph, and ensures the device consistently synchronizes its state to keep the user interface and automation engine accurate.