Abendly watches your IBM MQ estate continuously and read-only, surfacing the cause and the exact fix — early when there's a warning to catch, and the instant there isn't. It recommends; your engineer runs it. Raw logs never cross your network boundary.
For the teams that can't afford an MQ surprise
Every MQ incident leaves a trail before it becomes an outage — a depth trending up, a channel retrying, an event nobody was watching at 3am. Abendly watches that trail so the fix happens during the warning, not the outage.
A channel stops, a queue fills, a job abends. The alert fires, someone gets paged, and only then does anyone go reading logs to work out what happened.
Abendly is already reading the estate. It catches the trend, diagnoses the cause, and surfaces the fix to a human — with time to act before anything stops.
Prevention can't catch everything — a hardware fault or a fat-fingered config has no runway. So the same diagnosis engine runs both ways. Either way, it recommends the fix and a human runs it. Abendly never executes anything itself.
A continuous loop running inside your environment. It observes and it advises — it does not touch your queue managers. A human always runs the fix.
The agent reads channel status, queue depths, CF structures, MQ events, and error logs on an interval — across distributed and z/OS.
read-only access→The same engine behind Abendly's log analysis runs continuously — correlating signals into a root cause and a confidence level, before failure.
identifiers stripped first→You get a clear finding and the exact MQSC fix in execution order. Your engineer reviews and runs it. Nothing is auto-executed.
human runs the fixThe agent connects with a least-privilege service account that can inquire and display — and nothing else. This is what gets a monitoring tool past a bank's security review instead of stuck in it.
The service account holds inquire and display authority only. There is no code path that puts, alters, stops, or starts anything.
Hostnames, queue managers, channels, and user IDs are stripped to stable labels inside your boundary, before anything is reasoned over.
Bring your own AI provider — your Bedrock, Azure, or self-hosted model. Inference runs on your account under your governance, not ours.
Retrying, binding, and stopped states caught the moment they drift — before a sender channel gives up for good.
Depth measured against each queue's own baseline, so a slow climb toward MAXDEPTH is flagged with time to spare.
Coupling Facility structure usage and contention in a queue-sharing group, watched before it bites shared queues.
Channel, performance, and configuration events read straight from the SYSTEM.ADMIN event queues MQ already emits.
AMQERR logs on distributed and CSQ messages on z/OS, parsed continuously instead of waiting for a paste.
Findings fingerprinted from anonymized signals, so a problem that keeps coming back gets flagged as chronic, not new.
The agent is deployed inside your own environment and connects to MQ over your internal network. Nothing about your estate transits a network you don't control.
Stand it up in your cloud account or data center. It reaches MQ over the local network — MQ is never exposed to the internet.
Point it at your Bedrock, Azure OpenAI, or a self-hosted model. Reasoning runs on your provider, billed to you, governed by you.
With a self-hosted model, every step runs behind your firewall. Suitable for estates where production data cannot leave at all.
The questions a security team asks first, answered by how the product is built — not by a promise.
We'll connect a read-only agent to a single environment you choose, show it surface real findings from your own estate, and scope a deployment to your security and compliance requirements.
A read-only agent, in your environment, watching the estate that can't go down.
Request a demo →