In a scenario where the platform connects to another application with an external API during a transaction, Metrics "metric_instance" records might not be updated as expected.
In this particular, case, the Metrics "metric_instance" records are not updated if the transaction is being canceled before the "metric events" Business Rule runs. This happens if the call being made to the API is synchronous or async but within a synchronous code block.
In such cases, reviewing the transaction logs and DB insert/update statements can reveal that a connection with its target endpoint was canceled.
An example of LOG with the transaction being cancelled:
2019-12-17 00:05:05 (625) Default-thread-7 FA6866C1DB314454A80E45403996194F txid=c3e00c5ddbfd EXCESSIVE *** End #8160567 /incident.do, user: MaianPha, total time: 0:00:19.849, processing time: 0:00:19.849, SQL time: 0:00:00.038 (count: 52), business rule: 0:00:00.025 (count: 27), ACL time: 0:00:00.002, UI Action time: 0:00:00.001
2019-12-17 00:05:05 (619) Default-thread-7 FA6866C1DB314454A80E45403996194F txid=c3e00c5ddbfd Slow business rule 'eESM - AT&T eBond Update Incident' on incident:INC4599021, time was: 0:00:19.746
2019-12-17 00:05:05 (617) Default-thread-7 FA6866C1DB314454A80E45403996194F txid=c3e00c5ddbfd SEVERE *** ERROR *** *** Script: Error during: Update Incident. Message: Error executing SOAP request: Transaction cancelled: cancelled by user request. GUID: 4be004d1db310854a80e4540399619fe
As also explained in KB0693419 the execution order of Business Rules is important for the Metrics "metric_instance" records to be updated properly. For further information in the order of execution of scripts and other engines, check the following ServiceNow documentation: Execution order of scripts and engine
To avoid the issue, it's better to give the affected Business Rule an order of 10001+ ('metric events' = 10000) or, if possible, make it async.
More information about async Business Rules is availabe in the following ServiceNow documentation: How business rule work