Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full MuleSoft Observability entry
How-to guide

Configure and use MuleSoft Observability

Using MuleSoft Observability effectively spans initial configuration on the Anypoint Platform side, integration with Salesforce monitoring on the Salesforce side, and ongoing operational discipline around reviewing the metrics and acting on alerts. The walkthrough below covers the standard sequence for a customer with both MuleSoft and Salesforce.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 19, 2026

Using MuleSoft Observability effectively spans initial configuration on the Anypoint Platform side, integration with Salesforce monitoring on the Salesforce side, and ongoing operational discipline around reviewing the metrics and acting on alerts. The walkthrough below covers the standard sequence for a customer with both MuleSoft and Salesforce.

  1. Enable Observability in Anypoint Platform

    Log into the MuleSoft Anypoint Platform and confirm that Anypoint Monitoring (the foundation for Observability) is licensed and enabled for the relevant environments. Configure the monitoring data retention period based on the team's compliance and audit needs. Identify the APIs and applications that should be observable; by default, all deployed MuleSoft resources are tracked, but specific tagging or grouping can make the dashboards more useful.

  2. Configure Salesforce-side integration

    From Salesforce Setup, navigate to MuleSoft Observability and configure the connection to the Anypoint Platform. Authorize the integration with the appropriate scopes. Confirm that Salesforce-relevant metrics start appearing in the Setup page within a few minutes. Set the Salesforce admins who should have access to the MuleSoft Observability data through permission set assignments. Test the integration by triggering a MuleSoft integration that calls Salesforce and confirming the metric appears in the dashboard.

  3. Set up dashboards and alerts

    From the Observability dashboard, configure custom dashboards for the integration team: the top N APIs by volume, the top N by error rate, the SLA compliance view per critical integration. Configure alerts for the metrics that matter most: rising error rate, growing latency, approaching rate limits, anomalous traffic patterns. Route alerts to the team's incident management tool (Slack, PagerDuty, ServiceNow). Document the alert ownership so each alert has a clear primary responder.

  4. Operationalize the dashboard review

    Build the dashboard review into the team's weekly cadence. The integration team reviews the dashboards every Monday morning, flagging any growing error rates, latency creep, or anomalous patterns. Compare the metrics to the prior week and prior month to spot trends. Investigate any anomalies with the relevant API owners. Document any actions taken in the team's runbook. Without this discipline, the dashboards exist but no one looks at them, and the alerts become the only signal anyone responds to.

Gotchas
  • Anypoint Monitoring has its own data retention limits. Longer retention requires either a higher Anypoint tier or exporting metrics to an external system.
  • Alert noise is the biggest threat to operational use of Observability. Tune thresholds carefully to avoid alert fatigue.
  • Backend health metrics show only the systems MuleSoft connects to. Issues in systems further downstream (the ERP calls a tax service that is failing) require Observability on those systems too.
  • Sandbox versus production metrics should be reviewed separately. Combining them in one dashboard hides production issues behind sandbox noise.
  • Salesforce-side Observability shows API consumption against Salesforce limits but does not replace the standard Salesforce Limits Monitor. Use both for complete visibility.

See the full MuleSoft Observability entry

MuleSoft Observability includes the definition, worked example, deep dive, related terms, and a quiz.