The Integration That Stopped, Quietly

A client's integration kept stopping. Not breaking — stopping. No error, no failed job, no red banner. Mautic sat there looking perfectly healthy: cron running, plugin page saying "connected," dashboard full of last week's numbers. The only symptom was the absence of new data, and absence doesn't raise an exception. I found out late, every time, usually because a human downstream noticed something felt off.

Monitoring tells you when something breaks. Almost nothing tells you when something simply stops. A dead integration looks identical to a quiet Tuesday. You can't alert on fires that never happen — you have to alert on the absence of something that should have, which means deciding up front what "normal" is. Most of us have never written that down.

Watching a field breathe

The first version was almost stupidly simple: pick a contact field the integration is meant to keep updating, and check whether anything's written to it in the last X hours. Alive, the field keeps moving. Dead, it goes still — and stillness is something you can actually query for. Mautic already logs every field write. I just had to ask it.

Let's see what else we can do!

Once that worked, the obvious question turned up uninvited: what else in this instance is supposed to keep happening that I'd just assumed was fine? Three answers, each asking something slightly different:

Form submissions. Stop getting them and either the form's broken or the traffic dried up. Both worth knowing this week, not at month-end.

Emails sent. If mail stops going out, a campaign finished doing its job — or the transport's failing quietly. Only successful sends count, so a transport correctly rejecting everything still trips it.

Segment membership. Are contacts still entering the segments everything else feeds off? This is the sneaky one — it catches broken logic, not broken integrations. A filter that's quietly stopped matching anybody looks fine and is poisoning everything downstream.

"Is this one integration alive" quietly became "are the assumptions my whole automation rests on still true."

What it actually does

I called it IntegrationOwl — Mautic 5, MIT, github.com/jos0405/IntegrationOwlBundle.

The unit is a watch: did at least N of these things happen in the last X hours? Four types, each reading a table Mautic already fills — contact fields (audit_log), segments (lead_lists_leads), forms (form_submissions), emails (email_stats). Nothing external, nothing to sign up for.

Segment, form and email watches have a "watch any" switch: on, and the check passes if anything moved; off, and every ticked item has to move on its own — which catches one email in a sequence going quiet while its siblings mask the problem.

The interval is a tolerance, not a schedule — how long a silence you'll accept, not how often it checks. Minimum changes stops a single trickle from counting as healthy, catching degradation before it becomes death.

A small state machine alerts once when a watch goes stale, optionally repeats while it stays stale, and — the part everyone forgets — sends a recovered notice once it isn't. Skip that last bit and your monitor trains people to ignore it. There's a status page, run history, and the check command exits 0 even when watches are stale, because a stale watch is a finding, not a crash.

Do this even if you never install it

List the things in your instance that are supposed to keep happening. Not the things that might error — the things that just quietly stop. Then ask how you'd find out if one did, this week, before a human noticed first.

Most people can't answer that. It's not a knock — monitoring tools are built to watch for breakage, and stopping isn't breakage. It's the absence of something you never wrote down.