Tracking Policy Operations in the Activity Log
Every policy change on an external provider runs asynchronously, so a request that Anypoint accepts isn’t the same as a policy that’s applied on the gateway. Use the Activity log tab on an API instance to confirm what actually happened.
| Automate policy operation status checks using the MuleSoft MCP Platform Server. For details, see get_policy_operation_status in the MuleSoft MCP Platform Server Tool Reference. |
Before You Begin
Before getting started, make sure you have:
-
An Anypoint Platform account.
-
Access to the API instance whose Policies and Activity log tabs you want to view.
For more information, see Enhanced Experience Permissions.
Asynchronous Operations and Eventual Consistency
When you trigger a policy action, Anypoint accepts the request immediately and does the real work in the background: it talks to the provider, refreshes its view of the provider’s state, and records the outcome. As a result, the policy list is eventually consistent, it sometimes doesn’t reflect the change right after an action. The UI shows an optimistic view until the background job finishes and the state is reconciled.
Reading the Activity Log
The Activity log tab lists recent policy operations for the API instance. By default, it shows the last 10 activities from the last 30 days. Select Refresh to reload. If no operations have run in that window, the tab indicates that there are no recorded policy changes.
Each entry has these columns:
-
Action: the type of operation, such as Apply, Update (edit), Toggle (enable/disable), Remove, or Open (an open policy apply).
-
Policy: the policy the operation applies to.
-
Status: one of three states:
-
Running
-
Completed
-
Failed
-
Open an entry to see when it started and finished.
Interpreting a Failure
For a failed operation, open it to see why. The failure detail explains the error and, when applicable, whether the operation is safe to retry:
-
Transient failures come from a temporary problem, such as an unreachable gateway or a scan error. Try the operation again.
-
Other failures come from your configuration or the instance’s state. For example, an invalid configuration, a conflict with the instance’s current state, or a policy that can’t be translated for the target gateway. Fix the underlying issue before retrying.
For Amazon API Gateway, an operation can fail at two points with different outcomes. If it fails before deployment, the stage continues running its previous version and pending changes remain in the editable configuration. If it fails after deployment starts, the stage runs the new version even though the operation reports as failed. Failed operations don’t automatically undo changes made by the platform or by you. After a failure, check the AWS Management Console to see both the editable configuration and the deployed version, resolve any differences based on what you want the stage to run, rescan to refresh the view, and retry. See Amazon API Gateway Specific Behavior.