Monitoring Boomi integrations: what to watch and what to alert on

The worst way to learn that an integration has failed is from a customer: “I paid on Friday, why has my order not shipped?” This article explains what good integration monitoring looks like, then shows how to set it up for Boomi integrations: execution history, runtime health, alerts, and feeding errors into the monitoring tool the rest of IT already uses.

Why “email me on error” is not enough

Most teams start by sending an email when a process fails. It catches some problems and misses the dangerous ones:

• The process that never ran. The runtime was offline, the schedule was disabled, or the source stopped sending files. No execution means no error.
• The process that succeeded with nothing. The e-shop API returned an empty list because of an expired token on their side. Status: success, zero orders.
• The backlog. Messages queue up faster than they are processed. Nothing fails until something times out hours later.
• Alert fatigue. One email per failed document, two hundred emails during an ERP outage, and the real problem gets lost.

The pattern: four kinds of signal

Good monitoring for integrations watches four things:

Signal	Question	Example alert
Failures	Did something go wrong?	Order sync failed 3 times in 15 minutes
Absence	Did the expected thing happen at all?	No successful invoice export since 02:00
Volume/backlog	Is the amount of work normal?	0 orders processed in business hours; queue > 500
Expiry/health	Is something about to break?	Runtime offline; certificate expires in 21 days

Each alert should have an owner, a severity, and a link to the runbook that says what to do.

Step 1: Use Process Reporting for execution history

Process Reporting in Boomi shows every execution: process name, runtime, start time, duration, status, and the number of inbound and outbound documents. You can filter by process, status and time range, open an execution to see its documents and process log, and in many cases rerun failed documents.

Make it a habit, and a documented step in your runbook, to start every investigation here. Two practices make it far more useful:

• Name processes consistently, for example Orders | E-shop to ERP, so filters work.
• Add tracked fields to your documents (order number, customer ID such as C-1042) so you can search executions by business key instead of by time. Exact configuration of tracked fields depends on the connector and release.

Remember that execution history is kept for a limited time and may contain document data; take it into account in your retention and GDPR thinking.

Step 2: Watch runtime health

In Runtime Management (Atom Management in older releases), each runtime (Atom, Molecule or Atom Cloud attachment) shows its status. A runtime that goes offline stops all scheduled processes deployed to it, so this is the single most important health signal.

For runtimes you host yourself, also watch the basics: disk space (temp files and archives grow), memory, and the host’s own availability. Local runtimes can expose metrics over JMX, which most server monitoring tools can read.

If you use atom queues for asynchronous flows, check queue depths and dead-letter queues regularly in the queue management view.

Step 3: Set up email alerts and events

Boomi raises events for things like process errors, runtime status changes and messages you emit yourself. Users can subscribe to these as email alerts from their user settings, choosing the event types and severity levels.

1. Create a dedicated mailbox or distribution list, for example integration-alerts@company.gr, owned by the team on duty.
2. Subscribe it to process errors and runtime status changes for production.
3. Keep subscriptions for test environments separate, or off, so they don’t drown production alerts.

Emit business events with the Notify shape

For conditions that are not technical errors, use the Notify shape in your process with events enabled. For example, after fetching orders, a Decision shape checks whether the count is zero during business hours, and a Notify shape raises a warning event: No orders received from e-shop between 09:00 and 10:00. These events can reach the same email alerts and the API described below. Combine this with the error handling patterns in error handling and retries in Boomi, so that a caught error still produces a visible event.

Step 4: Send errors to your central monitoring tool

Email works for small teams. If the rest of IT uses Datadog, Grafana, Azure Monitor or a similar tool, integration alerts should go there too, with the same on-call rotation and escalation. Two common approaches:

• Pull from the Boomi Platform API. A small scheduled job queries execution records and events through the Platform API (the relevant objects include ExecutionRecord and Event; check the current API reference for exact fields and filters) and pushes metrics to your tool: failures per process, executions per hour, time since last success.
• Push from the process. An error-handling subprocess, called from the Try/Catch branch of your processes, posts a small JSON message to your monitoring tool’s HTTP intake with the process name, environment, error message and business key.

{
  "source": "boomi",
  "environment": "production",
  "process": "Orders | E-shop to ERP",
  "severity": "error",
  "businessKey": "SO-58812",
  "message": "ERP rejected order: customer C-1042 is blocked"
}

Do not send whole documents or personal data to the monitoring tool. Identifiers and the error message are enough to find the execution in Process Reporting.

Step 5: Alert on absence and backlog

The “nothing happened” alerts need something outside the process itself, because a process that does not run cannot report that it did not run:

• Time since last success: from the execution data you pull through the API, alert when the invoice export has no successful run since its expected time.
• Heartbeat: a tiny scheduled process that posts “I am alive” every few minutes; your monitoring tool alerts when heartbeats stop. This catches runtime and scheduler problems.
• Volume thresholds: alert when business-hours order counts drop to zero, or queue depth grows past a limit you have measured as abnormal.

Step 6: Track certificate and secret expiry

Certificates and client secrets are the most predictable failures of all. Boomi can show certificates with their expiry dates, and depending on your account, notify you about upcoming expiry. Add your own inventory and alerts 30 to 60 days ahead, as described in Managing secrets and certificates across environments in Boomi.

Before you go live

• Every production process has an owner and a runbook entry.
• Alerts route to people on duty, not to a mailbox nobody reads.
• Absence alerts exist for scheduled processes, not only error alerts.
• Alert storms are grouped: one alert for “ERP unreachable”, not one per document.
• No personal data in alert messages or external monitoring.
• Review alerts monthly: remove noisy ones, add ones for incidents you learned about the hard way.

Summary

Monitor four signals (failures, absence, volume and expiry), not just errors. In Boomi, Process Reporting and Runtime Management give you the history and health, email alerts and Notify events raise the signal, and the Platform API lets you bring it all into the monitoring tool the rest of IT already watches. For the wider picture of running integrations, see our guide DevOps for integrations.