AWS DevOps Agent - Troubleshooting bidirectional integration with ServiceNow

AWS DevOps Agent connects to ServiceNow so that a newly created incident can automatically trigger an investigation, and the resulting findings are posted back as Notes on the originating ServiceNow incident. The integration depends on three pieces working together: an OAuth client in ServiceNow, a Business Rule that delivers the webhook, and the AWS DevOps Agent provider that consumes the events and writes the findings back.

During the integration of the two systems(DevOps Agent and ServiceNow), the initial OAuth handshake completed, and the outbound webhook returned 200 OK against every ServiceNow record, indicating a successful integration. However, the following symptoms gradually surfaced:

• Investigation findings did not appear back on ServiceNow incidents.
• The first few incidents triggered investigations, then new incidents did not.
• AWS DevOps Agent provider logs showed: Access to unscoped api is not allowed.
• Amazon CloudWatch logs showed: Failed to process this event from ServiceNow: Invalid payload format.
• Incident timestamps in the AWS DevOps Agent web app displayed in GMT instead of the user's local timezone.
• Every incident was forwarded to AWS DevOps Agent, including non-AWS ones.

Each symptom traced back to a specific configuration choice on the ServiceNow side or a known AWS DevOps Agent behavior. This article walks you through each root cause and the resolution path so that you can troubleshoot a bidirectional ServiceNow integration issue in your own environment.

Solution overview This article addresses each failure mode in the order you should approach them. The first two cover the majority of "looks configured but nothing happens" cases:

1. Resolve the OAuth scope restriction that blocks AWS DevOps Agent from writing the findings back to ServiceNow.
2. Validate the webhook payload and event sequence so that every event reaches the agent with the required fields.
3. Map custom ServiceNow priority values back into the agent's supported 1–5 range.
4. Resolve timestamps that display in GMT in the AWS DevOps Agent web app.
5. Filter incidents at the source so that only AWS-related records reach the agent. The article closes with vended-log signals you can use for ongoing observability, and a list of factors to keep in mind as your ServiceNow customizations evolve.

Troubleshooting steps for the ServiceNow integration Resolving the OAuth scope restriction Cause: The OAuth client used by AWS DevOps Agent has the option Allow access only to APIs in selected scope enabled in ServiceNow. This restricts the client to a single application scope and prevents the integration from writing back to the global incident table when the agent posts the findings as Notes. Resolution: To clear the restriction, complete the following steps:

1. Sign in to ServiceNow with an account that has admin rights.
2. Navigate to System OAuth → Application Registry.
3. Open the OAuth client record that you created for the AWS DevOps Agent integration.
4. Clear the checkbox Allow access only to APIs in selected scope.
5. Save the record.
6. In the AWS DevOps Agent console, re-authorize the ServiceNow connection. If your security policy requires the scope flag to remain enabled, then grant the OAuth client explicit write access to the incident table instead.

Verification: Confirm that the OAuth client can still issue tokens after the change. Use any HTTP client (for example, Postman) to call the ServiceNow OAuth token endpoint at https://<YOUR_INSTANCE>.service-now.com/oauth_token.do. Send a request with the client credentials grant type, the OAuth client ID, and the secret. A successful response returns HTTP 200 with an access_token in the response body. After the change, investigation findings appear as Notes on the originating ServiceNow incident.

Validating the webhook payload and event sequence

Cause: When the webhook Business Rule fires, AWS DevOps Agent expects a payload that contains every required field for the event. If any field is missing, the agent rejects the request and the investigation never starts. The agent currently returns HTTP 200 even when validation fails, so the webhook appears successful from the ServiceNow side while the agent silently drops the event. A second cause: the agent treats incident_update as a follow-up to a previously seen incident_create. If the Business Rule fires only on update, or if the customizations skip the create event, then the agent has no record to update.

Required fields on every event. The following fields must be present on every webhook event:

Field	Description
sysId	The ServiceNow incident sys_id
eventType	Either incident_create or incident_update
priority	Numeric priority in the range 1–5 (see the next section)
incidentState	The incident state value from the source record
shortDescription	The incident short description

Resolution. To validate the webhook configuration, complete the following steps:

1. Open the ServiceNow Business Rule that delivers the webhook to AWS DevOps Agent.
2. Confirm that the rule fires on both insert (mapped to eventType: incident_create) and update (mapped to eventType: incident_update).
3. Verify that the JSON payload includes all five required fields in the previous table.
4. Inspect the response body recorded against each outbound REST call. The agent surfaces validation errors inside the response body's response_text field. Look for a message value of Invalid event body. This will return a 400 in the future, accompanied by an errors array that lists each missing property by name.

Mapping custom priority values to the supported range

Cause. The ServiceNow integration-specific webhook accepts only the standard ServiceNow priority range 1–5:

Priority	Meaning
1	Critical
2	High
3	Medium
4	Low
5	Planning

If your ServiceNow instance has been customized with priority values outside this range (for example, 6, 7, or 9), then the payload fails to parse and the event is dropped.

Resolution: Modify the webhook script in your Business Rule (or in a Script Include that it calls) to translate custom priority values back into the supported range before the payload is sent. The mapping does not need to be one-to-one. Group your custom values into the five supported buckets according to the operational meaning your organization assigns to each value.

Resolving timestamps that display in GMT

Cause: The AWS DevOps Agent web app derives display timezones from the browser. When the browser does not report a timezone (for example, when fingerprint-protection is enabled), the UI falls back to GMT. The underlying time values are correct - only the displayed label is GMT.

Resolution: To restore local time display, complete the following checks:

• Verify whether the workstation's browser has advanced privacy or anti-fingerprinting settings enabled. Examples include the Firefox privacy.resistFingerprinting flag, hardened browser extensions, and corporate browser policies that strip timezone hints. When timezone discovery is blocked, the agent falls back to GMT.
• Confirm that the operating system's timezone configuration matches the user's location.
• Compare the displayed hour values against the original ServiceNow record. If the hour values match local time but the label shows GMT, then the data is correct and only the displayed label is affected.

Filtering incidents at the source

Cause: By default, every incident the OAuth client can read is forwarded to AWS DevOps Agent. The agent then starts an investigation regardless of whether the incident is AWS-related. This inflates investigation counts and drives up the indirect service costs that AWS DevOps Agent incurs through Amazon CloudWatch Logs Insights, AWS X-Ray, and other connected services. Resolution: You can filter using either of two approaches:

• Option A - Filter inside the Business Rule script. Add a conditional check that delivers the webhook only when the incident's category or subcategory matches your AWS-related taxonomy. For example, only forward incidents where category equals AWS, or where subcategory indicates a cloud-related classification used in your instance.
• Option B - Filter using Business Rule conditions in the ServiceNow UI. Configure the When to run conditions on the Business Rule itself (for example, Category is AWS, or Assignment group contains Cloud Ops) so that the rule evaluates only for matching records. This approach keeps the script body simple and is easier to audit.
• Optional - Steering instructions inside the agent. You can additionally constrain agent behavior from the AWS DevOps Agent web app under Agents → Managed Agents → Incident Triage Agent → Edit instructions. Use this option to tell the agent to ignore or deprioritize categories that are difficult to filter at the source.

Key things to factor in When you operate the bidirectional integration in production, factor in the following:

• Silent validation failures: AWS DevOps Agent currently returns HTTP 200 for invalid payloads. Inspect the response body, not just the HTTP status, when you debug.
• Future-dated agent behavior: The validation warning "This will return a 400 in the future" signals that today's silent drop will become a hard error. Treat it as an action item, not a benign log line.
• Filter at the source: Unfiltered webhooks generate investigations on non-AWS incidents that drive up AWS DevOps Agent usage and the cost of any connected services the agent consults.
• Preserve priority intent: Map custom priority values back to the 1–5 range explicitly. Hard-coding every event to priority: 1 defeats triage logic in the agent.
• Timezone display vs. data: A GMT label in the web app does not mean timestamps are stored incorrectly. Verify the underlying values in the ServiceNow record before you escalate.

Conclusion

In almost every case, bidirectional ServiceNow integration symptoms trace back to one of the following:

• The Allow access only to APIs in selected scope flag on the ServiceNow OAuth client.
• A webhook payload missing one of the five required fields (sysId, eventType, priority, incidentState, shortDescription).
• Custom ServiceNow priorities outside the agent's accepted 1–5 range.
• The default unfiltered incident webhook firing on every record.

To learn more about how AWS Support plans and offerings can help you operate AWS DevOps Agent at scale, see AWS Support.

Sources

• AWS DevOps Agent User Guide — Connecting ServiceNow
• AWS DevOps Agent User Guide — Invoking DevOps Agent through Webhook
• AWS DevOps Agent User Guide — Vended logs and metrics
• AWS DevOps Agent User Guide — Autonomous incident response