The Service Control API provides a simple
services.check
method to check such preconditions. A managed service should call this method on
a regular basis to ensure the preconditions are met. The activity between the
service producer and the service consumer is represented by an
Operation.
The services.check method performs the following checks on the operation:
The service producer project is live and in a healthy state.
The service consumer project is live and in a healthy state.
The managed service is enabled on the service consumer project.
The API key is valid.
The use of the API key satisfies restrictions associated with the API key,
such as IP or HTTP referrer restrictions.
The services.check method is typically called from the servers that actually
implement the service. For security and privacy purposes,
the Service Control API uses Identity and Access Management to verify the
caller has the proper permission to call the method. For details, see
Service Control API Access Control.
Checking status
After you roll out a managed service, you can call the
services.check method on the service without additional configuration. See the
services.check
reference for details.
To quickly experiment with the method, you can use the gcurl command to call
the services.check method. See
Getting Started with the Service Control API
for the initial setup steps.
The response from the check method indicates whether all checks succeeded or
some checks failed. Success is indicated by the absence of
checkErrors
field. Otherwise, the checkErrors field lists the failed checks.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Checking Status\n\nThis page describes how to use Service Infrastructure for checking\nstatus on [managed services](/service-infrastructure/docs/glossary#managed),\n[service producers](/service-infrastructure/docs/glossary#producer),\n[service consumers](/service-infrastructure/docs/glossary#consumer), and API keys.\n\nWhen a service producer offers a service to its service consumers, it needs to\nensure that various preconditions are met, such as whether:\n\n- A service consumer has been deleted.\n- The service consumer has [enabled](/service-infrastructure/docs/glossary#enabled) the service.\n- An API key is valid.\n\nThe Service Control API provides a simple\n[`services.check`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check)\nmethod to check such preconditions. A managed service should call this method on\na regular basis to ensure the preconditions are met. The activity between the\nservice producer and the service consumer is represented by an\n[`Operation`](/service-infrastructure/docs/service-control/reference/rest/v1/Operation).\nThe `services.check` method performs the following checks on the operation:\n\n- The service producer project is live and in a healthy state.\n- The service consumer project is live and in a healthy state.\n- The managed service is enabled on the service consumer project.\n- The API key is valid.\n- The use of the API key satisfies restrictions associated with the API key, such as IP or HTTP referrer restrictions.\n\nThe `services.check` method is typically called from the servers that actually\nimplement the service. For security and privacy purposes,\nthe Service Control API uses [Identity and Access Management](/iam) to verify the\ncaller has the proper permission to call the method. For details, see\n[Service Control API Access Control](/service-infrastructure/docs/service-control/access-control).\n\nChecking status\n---------------\n\nAfter you [roll out](/service-infrastructure/docs/glossary#rollout) a managed service, you can call the\n`services.check` method on the service without additional configuration. See the\n[`services.check`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check)\nreference for details.\n\nTo quickly experiment with the method, you can use the `gcurl` command to call\nthe `services.check` method. See\n[Getting Started with the Service Control API](/service-infrastructure/docs/service-control/getting-started)\nfor the initial setup steps. \n\n```\ngcurl -d '{\n \"operation\": {\n \"operationId\": \"123e4567-e89b-12d3-a456-426655440000\",\n \"consumerId\": \"project:endpointsapis-consumer\",\n \"startTime\":\"2016-07-31T05:20:00Z\",\n \"operationName\":\"google.example.hello.v1.HelloService.GetHello\"\n }\n}' https://servicecontrol.googleapis.com/v1/services/endpointsapis.appspot.com:check\n{\n \"operationId\": \"123e4567-e89b-12d3-a456-426655440000\"\n}\n```\n\nThe response from the check method indicates whether all checks succeeded or\nsome checks failed. Success is indicated by the absence of\n[`checkErrors`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check#CheckError)\nfield. Otherwise, the `checkErrors` field lists the failed checks."]]