Common Errors and Warnings for ServiceNow – Backup

Error Message: We were unable to validate and add the service. Please check the instance URL and try again.

Reason: When setting up a new ServiceNow service, if the instance URL is incorrect, we're unable to validate and add the service.

Solution: Ensure the instance URL does not have any typos and revalidate the service.

Error Message: We were unable to validate and add the service due to an incorrect username or password. Please verify your credentials and try again.

Reason: When setting up a new ServiceNow service, if the username and/or password is incorrect, we are unable to validate and add the service.

Solution: Ensure the username and/or password is valid by logging into the ServiceNow instance, and that the user account has the admin role.

Error Message: Unauthorized_client: The [OAuth] client credentials provided are either not valid or not trusted.

Reason: When setting up a new ServiceNow service using OAuth, if the Client ID and/or Client Secret are incorrect, we are unable to validate and add the service.

Solution: Verify the Client ID and Client Secret are valid by referencing the credentials listed in the OAuth API Endpoint in your ServiceNow Application Registry.

Error Message: Missing permissions to read sys_db_object and sys_dictionary. The user requires the admin role or read permissions for those tables.

Reason: The data in the sys_db_object and sys_dictionary tables is retrieved in each backup to determine which tables and fields should be included in the backup.

Solution: Confirm the Own user account has valid ACLs/roles to read sys_db_object and sys_dictionary using Postman or ServiceNow REST API explorer.

Error Message: Data source IP restrictions are preventing Own from connecting; please add the appropriate Own IP(s) to your environment allow list. Refer to our knowledge base for further information.

Reason: The backup cannot retrieve data from the ServiceNow instance due to IP restrictions.

Solution: Reference platform_o_regions_for_allowlist_aws and platform_o_regions_for_allowlist_azure for information on allowlisting the Own IP addresses.

Error Message: Your Instance is hibernating please sign in to wake it up.

Reason: When setting up a new ServiceNow service, if the instance is a personal developer instance (PDI) and it’s hibernating, we are unable to validate and add the service.

Solution: Ensure the PDI is awake by logging into developer.servicenow.com to wake it up.

Error Message: Failed to backup [table_name] due to a 400 HTTP response from ServiceNow.

Reason: The URI does not match the ServiceNow APIs, or the operation failed for unknown reasons. This response indicates that the server can't or won't process the request due to something that is perceived to be a client error.

Solution 1: Confirm the user account has valid ACLs/roles to read the [table_name].

Solution 2: Exclude the table as described in Backup Exclusions in ServiceNow – Overview.

Error Message: Failed to backup [table_name] due to a 401 HTTP response from ServiceNow.

Reason: The user account credentials have changed and no longer provide valid authentication to communicate with ServiceNow’s APIs. Own is unable to receive a response from ServiceNow.

Solution: Re-authenticate the Own user account. See Reauthenticate Services for ServiceNow.

Error Message: Failed to backup [table_name] due to a 404 HTTP response from ServiceNow.

Reason: ServiceNow can not find the requested resource. It can mean the resource does not exist or an ACL constraint is preventing access.

Solution 1: Confirm the table exists in the ServiceNow instance.

Solution 2: Confirm the Own user account has valid ACLs/roles to read the [table_name].

Solution 3: Exclude the table as described in Backup Exclusions in ServiceNow – Overview

Error Message: Failed to backup [table_name] due to a 405 HTTP response from ServiceNow.

Reason: The HTTP action is not allowed for the requested REST API, or it is not supported by any API.

Solution: There is an error with the API request, open a Support ticket with the following info: your service region, service_id, backup_id, and table name.

Error Message: Failed to backup [table_name] due to a 406 HTTP response from ServiceNow.

Reason: Not acceptable. The endpoint does not support the response format specified in the request Accept header.

Solution: There is an error with the API request, open a Support ticket with the following info: your service region, service_id, backup_id, and table name.

Error Message: Failed to backup [table_name] due to a 415 HTTP response from ServiceNow.

Reason: Unsupported media type. The endpoint doesn't support the format of the request body.

Solution: There is an error with the API request, open a Support ticket with the following info: your service region, service_id, backup_id, and table name.

Error Message: Failed to backup [table_name] due to a 429 HTTP response from ServiceNow.

Reason: Too many requests. ServiceNow application nodes have reached their maximum queue limit and new transactions are being refused.

Solution: In the Options menu of the service, review the API Consumption options:

• To reduce errors and transaction timeouts, decrease the “number of records per each API request” and the “tables to process in parallel”. This will result in more API requests and longer backup times.
• To reduce backup times, increase the “number of records per each API request” and the “tables to process in parallel”. This will result in less API requests and increased errors.
• It is a balancing act between “number of records per each API request” and “tables to process in parallel”. Requesting too many records per request will result in more transaction timeouts. Increasing parallelism too high can result in HTTP 429 errors because too many requests are sent at once.

Error Message: Failed to backup [table_name] due to a 500 HTTP response from ServiceNow.

Reason: ServiceNow is sending a 500 HTTP response. The server has encountered a situation it does not know how to handle.

Solution 1: This is a non-specific error response. If the error persists, please open a Support ticket with the following info: your service region, service_id, backup_id, and table name. Our team will investigate internally.

Solution 2: Exclude the table as described in Backup Exclusions in ServiceNow – Overview.

Error Message: Failed to backup [table_name] due to a 502 HTTP response from ServiceNow.

Reason: The ServiceNow instance is unavailable due to an upgrade or maintenance.

Solution: Retry the backup.

Error Message: Internal error occurred when backing up [table_name]. Error: [error].

Reason: A catch-all error message for non HTTP errors. These errors are generally related to exceptions related to saving or writing to files.

Solution 1: Rerun a specific table backup to see if the error occurs again.

Solution 2: Open a Support ticket with the following info: your service region, service_id, backup_id, and table name.

Error Message: Failed to backup [table_name]. Error from ServiceNow: Unexpected Content-Type: , url: <url> , X-Transaction-ID: <transaction ID>

Reason: ServiceNow’s REST API responses contain an unexpected Content-Type value in the headers.

Solution: Reference the transaction ID posted in the message to locate the related transaction logs in the ServiceNow instance. Use the ServiceNow transaction logs to debug and resolve the issue.

Error Message: Failed to backup [table_name]. Error from ServiceNow: Transaction canceled: maximum execution time exceeded.

Reason: ServiceNow’s transaction quota rules have been exceeded. The execution of the query takes longer than what is defined in the Transaction Quota Rule. Once the set limit is reached, the instance will cancel any transaction in violation of the policy and notify the user of the cancelation. A similar message is also seen in the logs.

Solution 1: Adjust the “Maximum Duration (seconds)” of the Transaction Quota Rules related to the type of REST API request within ServiceNow. Navigate to System Definition > Transaction Quota Rules.

• Update both the REST Table API request timeout and REST and JSON Catch All transaction rule:
• Prevents inbound REST Table API transactions from running for longer than 60 seconds by default. Set this to 900 seconds (15 mins) or a comfortable duration.
• Update the REST Attachment API request timeout transaction rule for attachments:
• Prevents inbound REST Import Set API transactions from running for longer than 60 seconds (default). Set this to 900 seconds (15 mins), or a comfortable duration time.

Solution 2: In the Options menu of the service, review the API Consumption options. Decrease the number of records per each API request then the tables to process in parallel. Higher combinations can lead to more resource consumptions as multiple threads are running against the API.

Solution 3: Review the table(s) that are timing out. Evaluate if the table(s) contains customer data or system data.

• For system data, exclude the table(s). Before doing so, confirm the excluded tables do not have any relationships to mission critical tables. Excluding additional tables creates a potential risk when restoring data.
• Tables prefixed with “sys_” are system tables that can generally be excluded since they contain system generated data.

Error Message: Internal error occurred when backing up [table_name]. Error: Exception, detail: Response contained error message: Transaction cancelled: maximum number of SQL queries exceeded with detail: maximum number of SQL queries exceeded Check logs for error trace or enable glide.rest.debug property to verify REST request processing

Reason: ServiceNow’s transaction quota rules have been exceeded. The number of SQL queries executed exceeds what is defined in the Transaction Quota Rule. Once the set limit is reached, the instance will cancel any transaction in violation of the policy and notify the user of the cancellation, and similar messages are also seen in the logs.

Solution 1: Adjust the “Maximum Duration (seconds)” of the Transaction Quota Rules related to the type of REST API request within ServiceNow. Navigate to System Definition > Transaction Quota Rules.

• Update both the REST Table API request timeout and REST and JSON Catch All transaction rule:
• Prevents inbound REST Table API transactions from running for longer than 60 seconds by default. Set this to 900 seconds (15 mins) or a comfortable duration.
• Update the REST Attachment API request timeout transaction rule for attachments:
• Prevents inbound REST Import Set API transactions from running for longer than 60 seconds (default). Set this to 900 seconds (15 mins), or a comfortable duration time.

Solution 2: In the Options menu of the service, review the API Consumption options. Decrease the number of records per each API request then the tables to process in parallel. Higher combinations can lead to more resource consumptions as multiple threads are running against the API.

Solution 3: Review the table(s) that are timing out. Evaluate if the table(s) contains customer data or system data.

• For system data, exclude the table(s). Before doing so, confirm the excluded tables do not have any relationships to mission critical tables. Excluding additional tables creates a potential risk when restoring data.
• Tables prefixed with “sys_” are system tables that can generally be excluded since they contain system generated data.

Error Message: Failed to backup [table_name]. Error from ServiceNow: Incomplete JSON content

Reason: The API request has timed out.

Solution 1: Adjust the “Maximum Duration (seconds)” of the Transaction Quota Rules related to the type of REST API request within ServiceNow. Navigate to System Definition > Transaction Quota Rules.

• Update both the REST Table API request timeout and REST and JSON Catch All transaction rule:
• Prevents inbound REST Table API transactions from running for longer than 60 seconds by default. Set this to 900 seconds (15 mins) or a comfortable duration.
• Update the REST Attachment API request timeout transaction rule for attachments:
• Prevents inbound REST Import Set API transactions from running for longer than 60 seconds (default). Set this to 900 seconds (15 mins), or a comfortable duration time.

Solution 2: In the Options menu of the service, review the API Consumption options. Decrease the number of records per each API request then the tables to process in parallel. Higher combinations can lead to more resource consumptions as multiple threads are running against the API.

Solution 3: Exclude the table as described in Backup Exclusions in ServiceNow – Overview.

Error Message: Failed to backup table_name. Error from ServiceNow: (‘Connection broken: IncompleteRead() or ConnectionResetError()’)

Reason: The API request has timed out.

Solution 1: Adjust the “Maximum Duration (seconds)” of the Transaction Quota Rules related to the type of REST API request within ServiceNow. Navigate to System Definition > Transaction Quota Rules.

• Update both the REST Table API request timeout and REST and JSON Catch All transaction rule:
• Prevents inbound REST Table API transactions from running for longer than 60 seconds by default. Set this to 900 seconds (15 mins) or a comfortable duration.
• Update the REST Attachment API request timeout transaction rule for attachments:
• Prevents inbound REST Import Set API transactions from running for longer than 60 seconds (default). Set this to 900 seconds (15 mins), or a comfortable duration time.

Solution 2: In the Options menu of the service, review the API Consumption options. Decrease the number of records per each API request then the tables to process in parallel. Higher combinations can lead to more resource consumptions as multiple threads are running against the API.

Solution 3: Exclude the table as described in Backup Exclusions in ServiceNow – Overview.

Error Message: Failed to backup table_name due to malformed data. Error from ServiceNow: Last pulled primary key was not unique: [sys_id of primary key]. Failing section to prevent a time-out.

Reason: ServiceNow is sending records with duplicate primary keys. This can be caused by a faulty integration or a system table that is generating metrics against the same record. For example, sn_app_insights_aggregates.

Solution: Review the records in the table and determine if the duplicate primary key is generated by the system, or by a user. If it’s system generated, notify our Support team. If it’s generated by a user, remediate the duplicate primary key.