Amazon MQ Broker Health Sentinel

An Amazon MQ broker (managed ActiveMQ or RabbitMQ) that enters CRITICAL_ACTION_REQUIRED - Amazon MQ's own documented state for a problem like a full disk that needs operator attention - has no built-in way to say "notify this Slack channel right now" without wiring a CloudWatch alarm and SNS target per broker. This blueprint reads the broker's own state directly and alerts Slack the moment it stops being healthy.

How it works

1. periodic_broker_check (io.kestra.plugin.core.trigger.Schedule) runs every 10 minutes, explicitly passing aws_region and broker_id through its own inputs: block so the flow is self-contained when the trigger fires. Shipped disabled so a manual run can be verified first.
2. probe_broker_state (io.kestra.plugin.aws.cli.AwsCLI) runs aws mq describe-broker, capturing BrokerState, EngineType, and every other field the API returns as named task outputs.
3. evaluate_broker_state (io.kestra.plugin.core.flow.If) branches on whether BrokerState is CRITICAL_ACTION_REQUIRED or CREATION_FAILED.
   • then (CRITICAL): alert_broker_critical reports the broker ID, engine type, and exact state to Slack.
   • else (HEALTHY): log_broker_healthy records the current state, whether that is RUNNING or an expected in-progress transition.
4. log_audit_complete always runs last, printing the broker state regardless of which branch fired.
5. The errors block alerts Slack separately if the flow itself fails outright - a broker ID that does not exist, or bad credentials, must not read as HEALTHY.

What you get

• A HEALTHY/CRITICAL answer sourced directly from the broker's own control-plane state, not inferred from queue depth or connection count.
• Zero risk to the broker's own messages or queues - describe-broker is a pure control-plane read, unlike any approach built on consuming from the broker's own queues to check activity.
• A broker-agnostic check that works the same way whether the broker's engine is ActiveMQ or RabbitMQ, since BrokerState is a property of the Amazon MQ control plane, not the underlying message broker engine.
• A worked example of io.kestra.plugin.aws.cli.AwsCLI driving a read-only Amazon MQ control-plane audit, reusing the same corrected output-capture convention (newlines only, not spaces, stripped before the marker) as this repository's other AWS CLI-based sentinel blueprints.

Who it's for

• Platform teams running Amazon MQ brokers who need an immediate signal when a broker needs operator attention, without wiring a CloudWatch alarm and SNS target per broker.
• On-call engineers who want one Slack alert with the exact broker state instead of opening the Amazon MQ console to check manually.
• Anyone evaluating the AWS plugin who wants a worked example of AwsCLI reading a messaging service's own control-plane health, distinct from reading queue-level metrics or consuming messages.

Why orchestrate this with Kestra

Amazon MQ itself has no cross-broker "notify me the moment this broker needs attention" primitive beyond what you wire up separately in CloudWatch and SNS, configuration that then has to be kept in sync as brokers are created and retired. Kestra supplies the schedule, the HEALTHY/CRITICAL classification as a first-class branch, and an execution history that shows exactly when a broker's state changed.

Prerequisites

• An AWS account with an Amazon MQ broker deployed (update aws_region, broker_id).
• AWS credentials with mq:DescribeBroker permission - entirely read-only, cannot modify, reboot, or delete the broker.
• A Slack incoming webhook for alerts.

Local testing: describe-broker is one of the Amazon MQ operations LocalStack does implement (12 of 25 MQ operations, per LocalStack's own documentation), so this specific call is testable there in principle. However, LocalStack now requires its own account and auth token as of March 2026 regardless of which operations it implements, and LocalStack's own documentation notes it pins a single ActiveMQ version and does not support the RabbitMQ engine type at all - a real AWS account remains the most complete way to exercise this blueprint.

Secrets

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY: credentials for io.kestra.plugin.aws.cli.AwsCLI.
• SLACK_WEBHOOK_URL: Slack incoming webhook used by alert_broker_critical and the errors block.
• In Kestra OSS (no Enterprise secrets backend), secrets are supplied as environment variables prefixed SECRET_, base64-encoded - for example SECRET_AWS_SECRET_ACCESS_KEY=$(echo -n '<your-secret-key>' | base64) - and read back in flows with {{ secret('NAME') }}.

Inputs

• aws_region (STRING, default us-east-1): region whose broker is audited.
• broker_id (STRING, default <your-mq-broker-id>, must be replaced): broker to audit.

Outputs

• outputs.probe_broker_state.vars.BrokerState: the state this blueprint classifies on (verified enum from the AWS CLI's own command reference).
• outputs.probe_broker_state.vars.EngineType, EngineVersion, PendingEngineVersion, PendingSecurityGroups, PendingStorageSize, and more: also captured by this one call, available for further extension even though this blueprint only branches on BrokerState.

Quick start

1. Deploy an Amazon MQ broker in a real AWS account (ActiveMQ or RabbitMQ engine) and note its broker ID.
2. Add the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and SLACK_WEBHOOK_URL secrets.
3. Run the flow manually against a running broker and confirm log_broker_healthy fires.
4. There is no safe, reversible way to force CRITICAL_ACTION_REQUIRED on a real broker for testing purposes - validate the alert branch by temporarily editing the condition to match the broker's actual current state instead, then revert it.
5. Enable periodic_broker_check once you trust the check against your real broker.

How to extend

• Loop over several broker_id values with io.kestra.plugin.core.flow.Loop to audit every broker in an account in one run.
• Add a second, parallel branch that also alerts (at a lower severity) when PendingEngineVersion or PendingSecurityGroups is set, surfacing a pending change that will take effect on the next broker reboot before it is forgotten.
• Add a remediation branch that triggers aws mq reboot-broker once a human has confirmed the CRITICAL_ACTION_REQUIRED cause is one that a reboot resolves, behind an explicit approval gate - deliberately kept out of this sentinel so the monitoring path never reboots anything on its own.

Pitfalls

• CRITICAL_ACTION_REQUIRED is Amazon MQ's own catch-all critical state - its exact cause (for example, a full disk) is not broken out as a separate field in describe-broker's own response, so this blueprint's alert reports the state itself, not a root cause; the Amazon MQ console or broker logs are still the next step for diagnosis.
• DELETION_IN_PROGRESS is treated as healthy by this blueprint, not alarming - a broker being deliberately deleted is an intentional, expected transition, not an incident.
• The output-capture convention (tr -d '\n' | xargs -0 -I {} echo '::{"outputs":{}}::') deliberately does not strip spaces, the same corrected pattern used throughout this repository's AWS CLI-based sentinel blueprints.
• This blueprint is UNTESTED against a live AWS account. The CLI syntax and the BrokerState / EngineType output fields are taken verbatim from AWS's own CLI reference documentation - but no Kestra engine was run to execute this flow end to end.

Links

• Kestra AWS plugin documentation
• AWS CLI mq describe-broker reference
• Kestra secrets (OSS vs Enterprise)