01
Emergency Incident Response
Workers restarting, integrations stalled, queues backing up, or a deployment that will not come healthy. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.
MuleSoft Support
24/7 MuleSoft Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
AceMQ supports the Mule applications and integrations you run — workers restarting under memory pressure from payloads held in memory, DataWeave transformations that fall over at scale, connection pools exhausted against a backend system, VM queues backing up in the process layer, and worker sizing that quietly drives your bill. Every ticket reaches a named senior engineer.
Support quotes answered within 1 hour, by a senior engineer.
- min emergency SLA
- 15
- across Americas, EMEA, APAC
- 24/7
- enterprise customers
- 160+
- countries served
- 26+
Planning a build, upgrade or migration instead? See AceMQ MuleSoft consulting and services.
Customers
Partners
Incident Triage
MuleSoft problems we fix every week
These are real symptoms from real MuleSoft production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Mule app throws OutOfMemoryError on large file or payload processing | The streaming strategy on the source and on every component that consumes the payload. The default in-memory repeatable stream buffers the whole payload once it exceeds the initial buffer, so one large file plus concurrency exhausts heap. Repeatable file-store streaming is usually the fix. | 1–2 hours |
| CloudHub worker restarting repeatedly with no application error | Worker memory metrics against heap allocation for the worker size, plus the restart pattern relative to traffic. A worker cycling under memory pressure looks like an application crash in the logs but is a sizing and streaming problem. | 1–2 hours |
| DataWeave transformation takes minutes on a large array | Whether the script materialises the whole collection — indexed access inside a map, repeated lookups against an array instead of a keyed object, or a nested map producing quadratic work. We profile the script against a representative payload before changing runtime settings. | 2–4 hours |
| Calls to a backend system time out under load, backend looks idle | Connection pool configuration on the connector — max active connections, exhaustion action, and max wait. A pool sized below concurrency makes threads queue for a connection, so the wait happens before the request is ever sent. | 1–2 hours |
| VM queue depth growing in the process layer, messages delayed | Consumer concurrency on the VM listener against publish rate, and whether the flow downstream is doing synchronous work it should not. Persistent VM queues absorb the mismatch until they cannot, which is why the symptom appears late. | 1–3 hours |
| Deployment to Runtime Fabric fails or the app never becomes ready | Requested CPU and memory reservations against the available capacity on the fabric, then the readiness probe behaviour. Resource limits that cannot be satisfied leave the deployment pending with little in the application log. | 1–3 hours |
| Messages processed twice after a worker restart or redeploy | Transaction boundaries and acknowledgement mode on the source connector. Where a JMS or Anypoint MQ listener acknowledges before the flow completes, a restart mid-flow loses the work and the redelivery reprocesses it. | 2–4 hours |
| API policy applied in API Manager is not taking effect | Whether the autodiscovery configuration in the app matches the API instance ID and environment. A mismatch leaves the app running unpoliced while API Manager shows the policy as applied. | Same day |
Resolution times reflect typical MuleSoft engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your MuleSoft support contract
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
- 02
vCore & Worker Cost Governance
Worker sizing against measured heap and throughput, consolidating over-provisioned apps, and identifying integrations whose vCore consumption is driven by a fixable memory or streaming problem rather than real load.
- 03
Performance & Memory Tuning
Streaming strategy selection, DataWeave profiling and rewrite, connection pool sizing, thread and concurrency configuration, and heap analysis against real production payload profiles.
- 04
Root Cause Analysis
Every P1 closes with a written RCA: what failed, why, the fix applied, and the flow, connector, or runtime change that prevents recurrence. Delivered as standard, not on request.
- 05
Connectors & Backend Integration
JMS, Anypoint MQ, database, SAP, Salesforce, and HTTP connectors configured for the delivery semantics, retry behaviour, and error handling your integrations actually need under failure.
- 06
Upgrades & Deployment Models
Mule runtime upgrades, migration between CloudHub, CloudHub 2.0, Runtime Fabric, and on-premise runtimes, and moving integrations off MuleSoft entirely where that is the right commercial call.
Why AceMQ
What you get that you don't get elsewhere
We Treat vCore Spend as an Engineering Problem
Worker sizing is usually set once, during a project, and never revisited. We measure real heap and throughput, fix the memory behaviour that forced the oversizing, and document the change so the reduction survives the next release.
Named Engineers, Zero Cold Start
The same senior engineers stay on your account. They know your flows, your connectors, and your backend systems — so a P1 call starts with diagnosis, not twenty minutes of you explaining your integration estate.
Deep on the Messaging Behind the Flows
Most Mule incidents are really messaging incidents — acknowledgement modes, transaction boundaries, redelivery, ordering, and queue backpressure. Enterprise messaging is our core discipline, not adjacent knowledge.
No Tier-1 Triage Layer
You reach a senior engineer directly by phone, email, or Slack. No help desk collecting information to pass along, and no escalation approval standing between you and someone who can actually fix it.
We Debug the Layers the Vendor Won't
MuleSoft supports the Anypoint Platform. Your flows, DataWeave, connector configuration, streaming strategy, worker sizing, and the backend systems you integrate are yours — and that is where incidents originate.
Genuine Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone. Your 3am incident is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
We support MuleSoft wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- CloudHub & CloudHub 2.0
- Anypoint Runtime Fabric
- On-premise Mule runtime
- Mule 4.x runtimes
- Kubernetes & OpenShift
- AWS (EC2, EKS)
- Microsoft Azure (AKS)
- Google Cloud (GKE)
- Anypoint MQ & JMS brokers
- Bare metal & on-premise
- Air-gapped / restricted egress backends
- Hybrid cloud
Escalation Path
Your first hour of a MuleSoft outage
Every tier reaches a senior MuleSoft engineer. There is no tier-1 triage layer to get through.
- 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
- 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
- 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
- Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
T+Elapsed15:00
15-minute P1 response, 24/7.
A response time, not a resolution time.
- T+00:00Paged
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
- T+15:00Live
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
- T+30:00If needed
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
- AfterEvery P1
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
What does AceMQ MuleSoft support cost?
AceMQ MuleSoft support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
MuleSoft problems we've already solved
MuleSoft support and remediation work from AceMQ. Each card links to the full write-up: the integration estate, what AceMQ diagnosed or changed, and the result.
MuleSoft Streaming Strategy and OOM Remediation
Wholesale Distribution Group
Resolving out-of-memory failures in a Mule application that buffered entire multi-hundred-megabyte payloads because no repeatable streaming strategy was configured.
MuleSoft
Kubernetes
Docker
PostgreSQLMuleSoft CloudHub Worker Restart and Memory Pressure Support
Specialty Retail Chain
Investigating recurring CloudHub worker restarts under memory pressure and the application-level causes behind them.
MuleSoftDockerKubernetes
RedisMuleSoft Integration Estate Assessment
Regional Healthcare Network
Inventorying and evaluating a MuleSoft estate for reliability, error handling, and reuse before committing to either investment or migration.
MuleSoft
RabbitMQPostgreSQLKubernetesMuleSoft Migration and Licensing Cost Consulting
Mid-Market Manufacturing Group
An honest evaluation of which MuleSoft integrations justify their licensing cost, and a staged migration path for the ones that do not.
MuleSoftRabbitMQKubernetes
KongDocker
Support options
Four tiers of MuleSoft support.
AceMQ offers MuleSoft support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for the integrations your team runs, proactive monitoring that finds memory, pool and vCore problems first, Anypoint operated in your own MuleSoft tenant, and the runtimes and pipelines around Anypoint run on AceMQ infrastructure. Mule 3 and Mule 4 are covered.
- Tier 1
MuleSoft 24/7 Support & Incident Management
You run it, we back you up
- Live bridge in 15 minutes, 24/7, with a named senior engineer
- Heap, thread dump and connector pool analysis on the live worker
- Written root-cause analysis after every P1
Best for: Integration teams that run their own Mule applications and need senior cover when a nightly batch fails.
- Tier 2
MuleSoft 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Streaming strategy and DataWeave review against real payload sizes
- Connection pool and VM listener concurrency checks
- Worker and vCore sizing against measured heap and throughput
Best for: Estates where a worker restart loop or a vCore bill nobody can explain is not an acceptable surprise.
- Tier 3
Managed MuleSoft on Your Infrastructure
We run it in your cloud or data centre
- Deployment, environment and access management under change control
- Monitoring of application health, vCore use and queue depth
- Runtime Fabric upgrades, capacity and certificates where you run it
Best for: Teams that want their Anypoint integrations run to a standard without growing an integration on-call rota.
- Tier 4
Fully Managed MuleSoft on AceMQ Infrastructure
We host it and run it, as a service
- Customer-hosted Mule runtimes patched and replaced by AceMQ
- Maven and MUnit pipelines run by AceMQ
- Metrics, logs and alerting collected and watched by AceMQ
Best for: Teams that want integration operations handled end to end without running the surrounding infrastructure.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs MuleSoft day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for MuleSoft
Everything else AceMQ does for MuleSoft.
Support is one part of what AceMQ does for MuleSoft. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingMuleSoft consulting and services
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
Support for the rest of your stack
Messaging & Streaming
- RabbitMQ supportMessaging & Streaming
- Apache Kafka supportMessaging & Streaming
- IBM MQ supportMessaging & Streaming
- ActiveMQ supportMessaging & Streaming
- Azure Service Bus supportMessaging & Streaming
- Amazon SQS supportMessaging & Streaming
- Google Cloud Pub/Sub supportMessaging & Streaming
- Redpanda supportMessaging & Streaming
- Apache Pulsar supportMessaging & Streaming
- Message Queuing supportMessaging & Streaming
Databases & Caching
Search & Analytics
Lakehouse & Compute
Observability & Monitoring
Data Integration
Cloud & Containers
API Management
See support for all 51 technologiesShow fewer
Related services
What does AceMQ MuleSoft support include?
Our MuleSoft support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, performance and memory tuning, DataWeave optimisation, connector and backend integration work, runtime upgrades, and vCore cost governance. Every ticket is handled by a named senior engineer assigned to your account — there is no tier-1 triage layer and no per-incident charge.
Why does our Mule app run out of memory on large payloads?
Almost always the streaming strategy. Mule 4's default repeatable in-memory stream keeps the payload in heap once it grows past the initial buffer, and every concurrent request holds its own copy. A single large file is survivable; ten at once is not. Switching to repeatable file-store streaming moves the buffer to disk beyond a threshold, and combining that with a flow design that does not materialise the whole payload — avoiding operations that force the full stream into memory — usually resolves it without increasing worker size.
How is this different from MuleSoft's own support?
MuleSoft supports the Anypoint Platform and the Mule runtime as products. We support the integrations you built on them. Flow design, DataWeave, streaming strategy, connector and pool configuration, worker sizing, error handling, and the backend systems on both ends of your integrations are outside their boundary and inside ours. The two are complementary — we also help you build a clean, evidenced case for their support when an issue genuinely is a product defect.
Can you reduce our vCore consumption and Anypoint costs?
Frequently, yes. The pattern we see most is workers oversized to paper over a memory problem that has a real fix — usually streaming strategy or a DataWeave transformation that materialises a whole collection. Once that is corrected the app runs comfortably at a smaller size. We also look for apps that could be consolidated, non-production environments sized like production, and integrations that no longer serve a purpose. Every recommendation comes with measured evidence rather than a guess.
Our DataWeave transformation is slow. Is that fixable?
Usually, and in the script rather than the runtime. The dominant causes are indexed access inside a map producing quadratic work, repeated lookups against an array where a keyed object would be constant-time, and building large intermediate structures that are immediately discarded. We profile the script against a representative production payload, rewrite the hot path, and verify the output is byte-identical before it ships.
Do you support on-premise Mule runtimes and Runtime Fabric as well as CloudHub?
Yes, all of them, including mixed estates. Runtime Fabric and on-premise deployments hand you the infrastructure layer — resource reservations, readiness probes, node capacity, storage, and networking — which is where a large share of deployment and stability issues actually live. We support that layer alongside the Mule applications rather than treating it as someone else's problem.
Do you support Mule 3 applications and older Mule 4 runtimes?
Yes. Mule 3.9 reached end of life on 20 March 2024, and Mule 4 now ships in two channels: Edge releases up to three times a year with short support windows, and LTS releases each February with at least 18 months of standard support and 6 months of extended support. We support the runtime you run, plan the move to a supported LTS, and migrate Mule 3 applications, which means reworking MEL expressions and DataWeave 1.0 scripts rather than a version bump.
Do we still open cases with MuleSoft if we use AceMQ?
Only for genuine product defects. Your MuleSoft subscription stays the route for fixes to the Mule runtime and Anypoint Platform, and those cases stay under your own account. Day to day, your team calls us first: we triage, reproduce and fix what sits in your flows, connectors and infrastructure, and when the evidence points at the product we write the case with logs, thread dumps and a reproduction attached, so MuleSoft support starts from a diagnosis.
Can we work with AceMQ on MuleSoft without a long contract?
Yes. AceMQ works on MuleSoft in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
How much does AceMQ MuleSoft support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your MuleSoft environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how MuleSoft is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
When an Integration Stalls, Every System Behind It Waits
Reactive cover, proactive reviews, or AceMQ running MuleSoft for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior MuleSoft engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email a MuleSoft Architect
Get in Touch
Talk to a MuleSoft Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.