MuleSoft Health Check: 10 problems we find in almost every Anypoint estate

What a MuleSoft health check really finds: unapplied security policies, missing autodiscovery, secrets in config, unused billable flows, weak error handling. Ten findings from real reviews, with a checklist.

The short answer

A MuleSoft health check is a structured review of an Anypoint Platform estate: the deployed Mule applications, their configuration, the APIs in API Manager and Exchange, and the licence usage behind them. It compares what is really running against the organisation’s own standards and against MuleSoft good practice. The output is a ranked list of risks, each with evidence and a fix.

After 25 years in integration and many MuleSoft reviews, our main lesson is this: the problems are rarely exotic. The same ten findings come back in almost every estate, in public institutions, in healthcare and in global logistics. Most of them are invisible in Anypoint Studio and only show up when you compare code, platform and documentation side by side.

Why the same problems appear everywhere

MuleSoft makes it easy to build and deploy. It does not force anyone to apply the guideline that sits in Confluence. Projects start with a small team, the first APIs go live under time pressure, a partner leaves, and the standard is written later. The gap between “what we agreed” and “what is deployed” grows with every release. A health check measures that gap.

The 10 findings

1. Security policies are documented, but not applied. The API security guideline says every API needs JWT validation, client ID enforcement or rate limiting. API Manager tells a different story. In one review at a German association with more than 1.8 million members, none of the eight deployed APIs met the organisation’s own security guideline: JWT validation was missing on all eight, and two external APIs had no rate limiting.

2. API autodiscovery is missing. Without the api-gateway:autodiscovery element, the Mule application is not linked to its API instance in API Manager. That means no policy can apply, however carefully it was configured. We have seen this on production APIs that everyone believed were protected.

3. Secrets live in configuration files and in Git. API keys and passwords in config-*.yaml files, sometimes in a file called “secure”, but not encrypted. A typical sign: the same key value in every environment and in the example file. Even if it is a placeholder, it shows that the secure-properties pattern is not in place.

4. Keystores are packaged inside the application. JKS or P12 files with private keys, for example for the Salesforce JWT bearer flow, are shipped inside the deployable JAR. Anyone with Exchange or repository access can download them. Keys belong in a secrets store or a secure property, not in the artefact.

5. Internal APIs are reachable from the internet. System and process APIs should only be called by other APIs. On CloudHub 2.0 they often keep a public endpoint because nobody switched it off. In one estate, six of eight internal-class APIs had a public endpoint.

6. Billable flows that nobody uses. Hello-world apps, proofs of concept, test applications and failed deployments still count against the flow limit. In one estate we found that about one in twenty licensed flows could be freed at once, without touching a single business integration. We cover this in detail in our article on MuleSoft licence costs.

7. Error handling is missing or inconsistent. Scheduler flows without any error handler, global handlers that map everything to HTTP 500, and different error formats per team. The result: failed batch runs that nobody notices, and consumers that cannot tell a validation error from an outage.

8. DataWeave is written inline, everywhere. Multi-line transformations inside the flow XML are hard to test, hard to review and impossible to reuse. Moving them to .dwl files under src/main/resources is one of the cheapest quality gains in any Mule project. We find inline DataWeave in nearly every application we review.

9. The deployed API is not the published API. The specification in Exchange says version 1.3, the running application implements 1.1. Error responses such as 400, 401, 403 and 429 are missing from the spec. Health endpoints have no security scheme. In one estate, four of nine APIs ran an older specification than the one published to consumers.

10. Logs show payloads, but not the story. Full payloads, sometimes with personal data, are logged at INFO level, while a correlation ID across the call chain is missing. Hard-coded partner URLs instead of properties are a close relative: they work until the partner changes the endpoint.

The platform was never the risk. The gap between the guideline and what is deployed is.

A pattern behind the findings

Two more patterns show up in almost every review. First, older code written before the standard existed scores far lower than new code. In one review, new applications scored above 90 out of 100 against the house standard, while two older applications scored below 50. Second, standards contradict themselves. One guideline page says “never log in an error scope”, another says “log once where you map the error”. Developers then follow whichever page they read first. A health check makes such conflicts visible, so the architecture board can decide once.

Your self-check: 15 questions

• Does every deployed API have autodiscovery, in every environment including production?
• Do the policies in API Manager match your written security guideline, API by API?
• Are all passwords, keys and tokens in secure properties or a secrets manager, and different per environment?
• Are there any keystores or certificates inside your deployable JARs?
• Which system and process APIs have a public endpoint, and is that intended?
• Which deployments are test, PoC, failed or stopped, and still count as flows?
• Does every flow with an event source, including schedulers, have an error handler?
• Is there one error response format for all APIs?
• How much DataWeave is inline, and how much lives in tested .dwl files?
• Does the version running in each environment match the specification in Exchange?
• Do your specs declare 400, 401, 403, 429 and 500 responses?
• Is a correlation ID passed and logged across all layers?
• Is personal data ever logged at INFO level?
• Does every deployed application have an owner and a ticket or epic behind it?
• Do your MUnit tests run in the pipeline, with a coverage threshold?

If you answer “I don’t know” to more than three of these questions, your estate is like most estates we see. That is not a judgement, it is a starting point.

How we run a MuleSoft Health Check

Our health check takes two weeks and needs read-only access only: a connected app with view scopes on your Anypoint organisation. We use MuleInsights, our own analysis platform, to read the whole estate: business groups, environments, deployments, API Manager, Exchange and the Usage API. It parses the deployed applications from Exchange and checks them against your own development standard, not a generic checklist. Our architects then review the results, remove false positives and rank what matters.

You receive three things: a ranked findings list with evidence (file and line, API, environment), a short fix plan with effort estimates, and a licence view that shows freeable flows and when you will reach your limits. More about our MuleSoft practice is on our MuleSoft services page.

FAQ

What is a MuleSoft health check?
A structured review of an Anypoint Platform estate. It compares deployed applications, API policies, specifications and licence usage with your standards and with MuleSoft good practice, and ranks the risks with evidence and fixes.

How long does a MuleSoft health check take?
Ours takes two weeks for a typical estate of up to a few dozen applications. Larger estates take longer or are reviewed one business group at a time.

Do you need access to production?
We need read-only access only. Production is included because that is where the risk is, but we never change anything in your organisation.

Is the health check only for large companies?
No. Smaller estates often benefit most, because the standard is still young and the fixes are cheap.

What happens after the health check?
Your team can fix the findings alone, or we support with a fix sprint, a governance setup or an ongoing Center for Enablement service.

By Bassem Fawaz · #mulesoft #anypoint #health-check #api-security #integration