Troubleshooting ServiceNow Cloud Provisioning and Governance: A Practical Guide

Starting Your Diagnosis

Cloud Provisioning and Governance connects to cloud providers (AWS, Azure, Google Cloud) to create and manage resources. When provisioning fails, the cause could be in ServiceNow configuration, cloud provider connectivity, policy rules, or the request itself. Start by identifying where the problem is.

Ask: Is provisioning broken for all requests or specific requests? If all requests are failing, the problem is likely integration (connectivity to cloud provider, credentials expired). If only specific requests fail, the problem is likely policy (policy blocks the request) or configuration (request does not match cloud provider requirements).

Ask: When did this start? If provisioning worked until recently, something changed. Review recent policy updates, cloud provider API changes, or ServiceNow platform updates.

Where to Look in the Platform

Navigate to Cloud Provisioning and Governance configuration. Check that cloud provider connections are configured and status shows “healthy”. If status is “unhealthy”, credentials may be expired or connectivity is broken.

Check integration logs. Cloud Provisioning records all API calls to cloud providers. If a request fails, logs show what API call was attempted and what error the provider returned. This is your first source of truth for understanding what went wrong.

Check policy violations. If a request is rejected, governance policies may be the cause. Review which policies apply to the request and whether the request violates them. Common violations: resource type not allowed, region not allowed, tags missing, encryption not configured.

Check request details. The provisioning request record should show status (submitted, approved, pending, completed, failed). If status is “failed”, a reason should be logged. Review the reason and trace back to root cause.

Common Causes and Fixes

Cause 1: Cloud provider credentials are expired or revoked. Fix: regenerate credentials in the cloud provider (AWS IAM, Azure Service Principal, Google Cloud service account) and update them in ServiceNow Cloud Provisioning configuration. Test connectivity after updating.

Cause 2: Governance policy rejects the request (wrong region, missing tags, wrong resource type). Fix: either modify the request to comply with policy, or work with governance leadership to create a policy exception. Do not disable policies to work around this.

Cause 3: Cloud provider API limit reached. Some cloud providers limit how many resources can be created per hour. Fix: request quota increase from cloud provider or rate-limit provisioning requests in ServiceNow.

Cause 4: Request does not match cloud provider requirements. For example, requested instance type does not exist in the selected region. Fix: review cloud provider documentation for that region and update the request to use a valid instance type.

Cause 5: Integration workflow has a bug or missing step. For example, workflow calls API to create instance but does not wait for instance to be ready before declaring success. Fix: review workflow logic and add appropriate wait/retry logic.

Testing and Validation

Test connectivity to cloud providers. Use a simple test request (for example, create a small test VM) and observe whether it succeeds. Log the result and any errors returned.

Test policy enforcement. Submit a request that should violate policy and confirm that it is rejected. Submit a request that complies with policy and confirm that it is approved. This validates that policies are working as intended.

Test end-to-end workflow. Submit a request through the entire provisioning process and confirm that the resource appears in the cloud provider account with expected configuration. Check that tags, encryption and other properties are set correctly.

Test error handling. Stop the cloud provider service temporarily and submit a provisioning request. Confirm that ServiceNow handles the unavailability gracefully (does not hang, logs error, allows retry). Restart the service and confirm provisioning can complete.

Escalation Points

If credentials are expired and updating them does not restore connectivity, the root cause may be cloud provider account issues (permissions revoked, account suspended). Escalate to cloud account owners for investigation.

If integration logs show cloud provider returning unexpected errors, the cloud provider API may have changed. Check cloud provider release notes or escalate to the cloud provider for clarification.

If provisioning workflow appears to be hanging (requests stuck in “pending” status for hours), escalate to ServiceNow support. The issue may be a platform bug or missing configuration.

Preventing Future Issues

Monitor cloud provider credentials and set up alerts when they are close to expiration. Rotate credentials on a schedule (annually) rather than waiting for them to expire.

Track cloud provider API changes and update your integration accordingly. Subscribe to cloud provider security bulletins so you know when APIs are deprecated.

Review provisioning failures weekly. If the same failure is happening repeatedly, that is a signal to fix the root cause rather than working around it.

Document workarounds temporarily but fix the root cause. If you enable a policy exception to work around a policy that is too strict, that is temporary. The real fix is updating the policy.

Working out which side of the record is wrong

When a provisioning request looks wrong, the most useful first question is not what failed but which copy of the truth is wrong. The request record in ServiceNow says one thing, the cloud provider says another, and the configuration item may say a third. Each can be right or wrong, and fixing the wrong one first wastes time. An on-call engineer should compare the three states before touching any setting, then choose the repair that matches what they found.

The comparison is quick when it is done in a fixed order: request record, integration log, provider console, then the configuration item the request should have produced. Stop at the first point where the states disagree. That point is where the fault most likely sits.

Reading the three states together

The partial-provisioning row is the one that can cause the most damage. A retry from the request form will create a second resource unless the workflow checks for the first one, so the rule of thumb is that a request with a resource identifier is never retried by resubmitting it.

Recovering a partial provisioning

A partial provisioning means the cloud resource exists but the request does not describe a working, governed resource. Recovery is about making the record and the resource agree without creating a second resource. Follow this sequence:

1. Copy the resource identifier from the integration log, and confirm in the provider console that it is the resource the request created, using the request tags and creation time.
2. Record the step that failed, the error text and the time, so the fault can be reproduced later.
3. Apply the missing tags or policy attributes to the existing resource through the same route a normal change would take.
4. Link the resource to the request and the configuration item, rather than creating a new configuration item.
5. Move the request to its completed state only after the link is confirmed, and add a note saying the completion was manual.
6. Find other requests that failed at the same step during the same window, because a single cause often produces several partial resources.

When the fault is in the connection, not the request

If many requests fail in the same way, look at the connection before the requests. Expired or rotated credentials, a change in the provider’s permission model, and a provider-side quota can all produce the same pattern: a wave of failures with similar errors. The integration log will show whether the calls are reaching the provider at all. If they are not, the problem is network or credential related. If they reach the provider and return a refusal, read the refusal message carefully, because provider error text is often more specific than the status the request record shows.

Do not widen the integration account’s rights to clear a refusal. Find the specific action being refused, grant the narrowest right that allows it, and record the change so the review can see why the account now holds it.

Questions on-call engineers ask

Can I cancel a failed request and submit a new one?

Only when the record shows no resource identifier. If a resource identifier exists, cancelling and resubmitting risks a second resource. Check the provider first, and use the recovery sequence above.

Why does a request show completed when the resource is wrong?

The completion state reflects what the workflow did, not what the cloud looks like now. Anything changed later outside the process will not update the request, which is why the change history of the resource is the first thing to read.

How do I know when to escalate?

Escalate when the three states disagree and the integration log does not explain why, or when the same failure appears across several requests after credentials have been checked. Include the request identifiers, the log excerpts and the provider console state in the escalation.

Should failed requests be cleared in bulk?

Not until each one has been classified as clean, partial or policy-rejected. Bulk clearing can hide partial resources, which then surface later as cost records with no owner.

For designing the connection so that retries are safe, the integration patterns section is the place to start, and the integration error handling post covers how failed integration calls are handled and reviewed.