What Is Amazon EventBridge? The Wiring Behind Alarms

Amazon EventBridge is the routing layer that can turn an AWS event into an automatic reaction: a CloudWatch alarm changes to ALARM, EventBridge receives the state-change event, a rule decides whether that exact event matters, and a target such as Lambda, SNS, SQS, or another AWS service receives it. The surprising part is that you do not need a polling script asking CloudWatch whether an alarm changed. CloudWatch sends alarm state-change events directly to EventBridge and guarantees delivery of those alarm state-change events. EventBridge is not mandatory for every alarm action, but when we built event-driven alarm automations, it was the wiring that connected detection to reaction. To wire one up, create a rule on the default event bus that matches CloudWatch Alarm State Change, then attach a target.

Imagine Jake's phone shop has a server alarm. CloudWatch is watching the measurement. EventBridge does not measure the CPU, count the errors, or decide that the threshold was crossed. CloudWatch does that job.

EventBridge becomes useful after the state changes. It can look at the event describing that change and route it to the system that should react.

What is Amazon EventBridge in plain English?

Amazon EventBridge is a serverless event-routing service. The word serverless here means you use the service without operating EventBridge servers yourself. The word event means a structured description of something that happened.

An EC2 instance can change state. An application can create an order. An AWS service can report a resource change. A CloudWatch alarm can move from OK to ALARM. These are all things that can become events.

EventBridge receives events and routes selected ones toward consumers.

Something happens
       |
       v
     Event
       |
       v
  EventBridge
       |
       v
Does a rule match?
    /       \
  yes        no
   |          |
   v          v
Target      Ignore

That simple picture explains an enormous amount of AWS automation.

You can let one application publish an event without teaching it how to call every downstream application. You can change which consumers react without rewriting the producer. That is the basic value of event-driven architecture: components can communicate through events instead of being tightly wired directly into each other.

Ethan says it more sharply: “Do not give EventBridge every job in the diagram. CloudWatch notices the condition. EventBridge decides which event-driven road the result travels down.”

That distinction matters later when you troubleshoot. If the threshold never caused a CloudWatch state change, editing an EventBridge rule will not fix the problem. You would be repairing the wiring when the detector itself never changed state.

Why EventBridge felt like the wiring behind our alarms

CloudWatch alarms can already support direct alarm actions for several use cases. So saying “every alarm requires EventBridge” would be wrong.

What EventBridge gives us is a reusable event-routing layer.

Suppose Jake has an alarm called ShopApiHighErrors. He wants three different teams or systems to react differently:

• Operations wants a notification.
• An automation function wants to collect diagnostic information.
• A separate workflow wants to open an incident only for a particular class of alarms.

You could bolt all of that logic into the place where the condition was detected. Or you could let the alarm emit its normal state-change event and let EventBridge routes decide which consumers care.

That is why EventBridge feels like wiring. The alarm does not need to understand every device at the end of every wire.

It produces the event. EventBridge examines the event. Consumers react.

More importantly, consumers can be added later. A security workflow can begin listening for certain events without forcing the original producer to be rewritten around that new requirement.

That is the practical meaning of “loosely coupled.” It does not mean nothing is connected. It means the producer does not have to carry every consumer's implementation details.

The four parts: event, bus, rule, target

Event is the message.

Event bus is the road junction.

Rule is the traffic officer deciding which messages take which exit.

Target is the destination.

The distinction between a bus and a rule trips up beginners because the console can make them feel like parts of the same screen. They have different jobs.

A rule belongs to an event bus. A rule only evaluates events on that bus. That becomes important when you accidentally create a beautiful rule on a custom bus while the AWS service event you care about is arriving on the default bus.

The event and your rule can both be individually correct while never meeting each other.

That is the EventBridge equivalent of putting the right letter in the wrong mailbox.

What CloudWatch actually sends when an alarm changes state

CloudWatch sends events to EventBridge when an alarm is created, updated, deleted, or changes state.

For the automation path in this post, the event type we care about is:

CloudWatch Alarm State Change

The event source is:

aws.cloudwatch

A state-change event contains top-level information such as the event source, Region, account, resources, and event type. Its detail section includes alarm information.

For a normal single-metric alarm, the state section includes a value such as:

{
  "detail": {
    "state": {
      "value": "ALARM"
    }
  }
}

That nested structure is important. If you want a rule that triggers only when an alarm enters ALARM, your event pattern must match the field where the value actually lives.

A broad pattern for all CloudWatch alarm state changes is:

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"]
}

A narrower pattern that asks for the new ALARM state is:

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

Now your rule is no longer saying “tell me every time any alarm changes state.” It is saying “tell me when a CloudWatch alarm state-change event reports that the new state is ALARM.”

You can narrow again by matching alarmName inside detail when the rule should react only to one named alarm.

This is a much safer pattern than creating a broad rule and teaching the Lambda function to discard 99% of the events after invocation. Filtering early reduces unnecessary downstream work and makes the intent visible in the routing layer.

ALARM, OK, and INSUFFICIENT_DATA: state change is the trigger

A rule listening for an alarm state change does not mean it runs continuously while the alarm remains red.

The significant word is change.

If the alarm changes from OK to ALARM, CloudWatch produces a state-change event.

If it later moves from ALARM back to OK, that is another state-change event.

If a newly created alarm moves through INSUFFICIENT_DATA and then gets enough information to evaluate, that can produce another transition.

So a broad rule can receive more than just “something is broken” events.

If you need repeating behavior while a condition remains true, you are solving a different problem. Do not try to make an alarm transition behave like a recurring schedule.

This one misunderstanding creates a surprising number of “EventBridge stopped working” investigations when EventBridge did exactly what the rule asked.

Build the CloudWatch alarm EventBridge rule in the console

For a normal AWS service event such as a CloudWatch alarm state change, begin with the default event bus and a Classic rule.

1. Open the Amazon EventBridge console in the same Region where you are working with the alarm.
2. Open Rules.
3. Choose to create a rule.
4. Give it a name that describes the reaction, such as RouteShopApiAlarmToDiagnostics.
5. Select the default event bus for the normal AWS service event.
6. Create an event pattern using aws.cloudwatch as the source.
7. Match CloudWatch Alarm State Change as the detail type.
8. Add detail.state.value = ALARM if you only want transitions into ALARM.
9. Add the alarm name if this rule belongs to one particular alarm.
10. Select the target that should react.
11. Configure target permissions as required.
12. Choose an appropriate retry policy and dead-letter queue for important delivery paths.
13. Review the rule and create it.

Then remember something that is easy to miss: changes to targets can take a short period to take effect. Do not create or change a target and immediately conclude the rule is broken because the first instant after the change did not behave like a long-settled configuration.

I also prefer names that describe intent rather than names such as eventbridge-rule-1. Six months later, RouteHighErrorAlarmToIncidentLambda tells you much more without opening the rule.

Create the same alarm rule with the AWS CLI

The Classic EventBridge rule commands live under the AWS CLI events namespace.

First create or update the rule with put-rule:

aws events put-rule \
  --name "RouteShopAlarm" \
  --event-pattern '{
    "source": ["aws.cloudwatch"],
    "detail-type": ["CloudWatch Alarm State Change"],
    "detail": {
      "state": {
        "value": ["ALARM"]
      }
    }
  }'

Then attach a target with put-targets.

For a Lambda target:

aws events put-targets \
  --rule "RouteShopAlarm" \
  --targets \
  "Id"="AlarmHandler","Arn"="arn:aws:lambda:us-east-1:123456789012:function:AlarmHandler"

If you want to inspect the rule afterward:

aws events describe-rule \
  --name "RouteShopAlarm"

And list its targets:

aws events list-targets-by-rule \
  --rule "RouteShopAlarm"

Those two inspection commands answer an important question when automation was deployed by somebody else: what does this rule actually match, and where is it actually trying to send the result?

Do not assume a target exists just because the rule exists. Rules and targets are separately visible parts of the configuration.

The rule matched, but nothing happened: target permissions

This is the failure mode that makes people blame the event pattern long after the pattern has done its job.

EventBridge needs permission to use the target.

Lambda, SNS, and SQS can use an execution role or resource-based target permissions in current Classic target configurations. CloudWatch Logs uses resource-based permissions. Other target types have their own permission requirements.

This gives us a diagnostic rule that is worth remembering:

If the event did not match, inspect the event and pattern.

If the event matched but delivery failed, inspect target configuration, permissions, throttling, and the target itself.

Those are different categories of failure.

Do you have to send the entire alarm event to the target?

No. Classic EventBridge rules support input transformation before delivery to a target.

This is useful because the event that is perfect for EventBridge filtering is not always the event shape that is convenient for the consumer.

Imagine your downstream notification function really needs only:

• alarm name,
• new state,
• reason,
• Region,
• timestamp.

You do not necessarily need the target to receive every nested configuration detail and then write repetitive parsing code for a simple use case.

An input transformer lets the routing layer extract values from the source event and build the target input in the shape you want.

The important architectural choice is where transformation belongs.

If the same transformed shape is useful to one target, transforming at the rule can be clean.

If several downstream consumers need different business interpretations, do not turn one EventBridge rule into a miniature application. Keep complex logic in an appropriate consumer such as Lambda.

Ethan's rule of thumb is: “Use EventBridge to route and reshape. Use application code when the decision has become business logic.”

What happens if EventBridge cannot deliver the alarm event?

For a Classic rule target, EventBridge has a retry policy.

The default maximum event age is 24 hours, and the default maximum number of retry attempts is 185.

Those values describe delivery behavior, not alarm evaluation behavior.

CloudWatch has already produced the event. EventBridge is now trying to get that event to the target.

You can change the retry policy when configuring the target.

Long retries make sense when temporary target problems should be allowed time to recover.

Shorter windows can make sense when an event becomes useless quickly. A remediation command that arrives many hours after the incident may not be desirable simply because delivery was eventually possible.

The right value depends on what the target action means.

Why important rules need a dead-letter queue

A dead-letter queue, usually shortened to DLQ, is where failed deliveries can be preserved after EventBridge can no longer successfully deliver them under the configured retry policy.

For Classic rule targets, EventBridge uses an Amazon SQS standard queue as the DLQ.

Without one, an exhausted delivery can disappear from the normal processing path, leaving metrics as your clue that something failed.

With one, you have the failed event available for investigation.

That matters in alarm automation because the most interesting delivery failures tend to happen at the worst time: permission changes, throttling, downstream outages, broken deployment configuration, or a target that no longer exists in the expected form.

For an important alarm workflow, I would rather open an SQS DLQ containing the failed event than reconstruct what probably happened from memory the next morning.

How do you monitor the thing that monitors your alarms?

This is where event-driven systems become real operations rather than diagrams.

You need visibility into EventBridge itself.

If deliveries fail, FailedInvocations is one of the metrics that can reveal target invocation failures.

If you configured a DLQ, InvocationsSentToDlq can show deliveries being sent there.

IngestionToInvocationSuccessLatency helps expose the time from event ingestion to successful target invocation. That can reveal a system that technically succeeds but is becoming slower because of retries or a struggling target.

A healthy architecture therefore watches both sides:

• Is the source producing the events?
• Is EventBridge delivering them successfully?

A green source metric does not prove the target was invoked.

A healthy target does not prove the event matched the rule.

Each link in the chain owns a different kind of evidence.

EventBridge rule not triggering? Diagnose it in this order

Do not start by deleting and recreating the rule.

Trace the route.

1. Confirm the alarm really changed state. If the alarm remained in the same state, there may be no new state-change event for the rule you built.
2. Confirm the Region. Make sure you are looking at the rule and event source in the Region you intended.
3. Confirm the event bus. Normal AWS service events sent to EventBridge arrive on the default event bus.
4. Inspect the event pattern. Check source, detail-type, nested fields, alarm name, state, and capitalization.
5. Confirm the rule is enabled. A perfect disabled rule is still a disabled rule.
6. Confirm a target is attached. Do not assume the existence of the rule proves the target configuration exists.
7. Inspect target permissions. EventBridge must be authorized to invoke or write to the target.
8. Inspect EventBridge metrics. A failed invocation points you toward delivery rather than event matching.
9. Inspect the target's own logs and metrics. A successful EventBridge invocation does not prove your target application logic succeeded.
10. Inspect the DLQ. If configured, failed deliveries may be waiting there with exactly the event you need to investigate.

Symptom: the alarm is ALARM, but the rule never runs

Ask whether it changed to ALARM after the rule was ready. A rule matching a state-change event is not a query for the alarm's current state.

Symptom: a broad pattern works, but the specific pattern does not

Your narrowing field is the likely problem. Compare its nesting and exact value against a real event. If removing the alarm-name filter makes the rule work, inspect the alarm name. If removing the state filter makes it work, inspect detail.state.value.

Symptom: the rule invokes some targets but not one target

That strongly points toward the target configuration or target-specific permissions rather than the event pattern. The same event already matched the rule.

Symptom: console setup works, CLI setup does not

Compare the permission resources created or configured by the console path with what you created manually. The EventBridge target reference and the target's permission to accept delivery are separate requirements.

Default bus vs Custom Event Bus vs Classic: the 2026 naming trap

This is unusually important because tutorials written before September 2026 can use the words custom event bus and mean something different from a new tutorial using the same words today.

The default event bus remains the important bus for the ordinary AWS service events in our CloudWatch alarm example.

Custom Event Bus - Classic is the older rule-and-target custom-bus model.

The enhanced Custom Event Bus uses subscribers created by consumers and retains events for a period you configure.

For a new custom event-driven application, the current product direction points you toward the enhanced Custom Event Bus.

For understanding a CloudWatch alarm event arriving on the default bus and being matched by a Classic rule, the older rule-and-target vocabulary is still exactly the vocabulary you need.

Do not migrate an alarm tutorial mentally into the subscriber model halfway through. First identify which bus model the instructions are using.

EventBridge vs SNS vs SQS vs Lambda

These services appear together so often that beginners can reasonably wonder why AWS needs four different names for “send something somewhere.”

They solve different parts of the problem.

You can combine them:

CloudWatch Alarm
       |
       v
EventBridge Rule
       |
       +----> Lambda
       |
       +----> SNS
       |
       +----> SQS

A Classic rule can technically have up to five targets, but the easier-to-maintain design is often one target per rule. If two consumers need the same event, duplicate the event pattern into separate rules so each consumer can evolve independently.

That costs you a few more named rules and often saves you a much more expensive future conversation beginning with, “Why did changing the notification pipeline break the remediation pipeline?”

EventBridge rules vs Pipes vs Scheduler

EventBridge now covers more than event-bus rules, so a tutorial that simply says “use EventBridge” is leaving out an important decision.

Event buses fit event-routing problems: many possible producers, filtering, and one or more consumers.

EventBridge Pipes fit point-to-point integration. A pipe connects one supported source to one target and can apply filtering, transformation, and enrichment along the way.

EventBridge Scheduler fits time-driven work. If the requirement is “invoke this at 9:00 a.m. every weekday,” that is fundamentally different from “invoke this when an alarm enters ALARM.”

The quotas that matter after your first five alarms

A tiny alarm workflow makes EventBridge feel limitless because you are nowhere near any meaningful boundary.

Production design requires you to know where scope lives.

A Classic rule can have a maximum of five targets. That quota is not adjustable.

The default rule quota is scoped per event bus and per account in a Region, and EventBridge exposes adjustable quotas for several larger-scale limits.

The important habit is never writing a naked number such as “the EventBridge limit is 300.” Ask what the number is attached to.

• Per rule?
• Per bus?
• Per account?
• Per Region?
• Per endpoint?

Capacity limits are almost meaningless without their scope.

If you design for several teams, separate ownership matters as much as raw count. A single event bus with hundreds of unrelated rules can become an organizational problem before it becomes a quota problem.

What does EventBridge cost?

As of October 2026, the first question before doing EventBridge cost arithmetic is: which EventBridge bus model are you using?

The enhanced Custom Event Bus introduced in September 2026 uses data-volume pricing for ingress and egress.

Custom Event Bus - Classic keeps the older event-based model.

For Classic custom events, the current US pricing examples use $1.00 per million custom events ingested. Event payloads are billed in 64 KB chunks in that model.

Worked example: 10 million Classic custom events

Suppose your own application publishes 10 million custom events to a Classic event bus in one month, and each fits inside one 64 KB billing chunk.

That does not mean the whole application costs $10.

Cross-account delivery, target services, payload size, API destinations, archives, replay, data transfer, and other EventBridge capabilities can add charges.

The newer Custom Event Bus should not be estimated by copying the Classic $1-per-million figure. Its billing model is different.

This is exactly why an old EventBridge cost sentence can be technically correct and still be wrong for the architecture you are building today.

Cross-account EventBridge: the wiring leaves Jake's account

EventBridge becomes especially useful when one AWS account owns the source and another owns the consumer.

Imagine Jake eventually puts shared monitoring in a central operations account while the shop application stays in its own account.

An event can be routed toward an event bus in another account, but cross-account design introduces a second layer of questions:

• Does the receiving event bus allow the sender?
• Does the sending configuration have permission to publish there?
• Is an IAM role required for the target configuration?
• Does the rule filter events before forwarding so the central account receives only what it needs?

A cross-account EventBridge problem should therefore not be reduced to “my pattern looks correct.”

The resource policy on the destination side is part of the route.

Organizations can simplify some sharing patterns, but organization-wide permission is still permission. If the business requirement allows only two accounts to publish, a policy allowing an entire organization may be broader than necessary.

The cleanest cross-account architecture sends only the events the destination really owns. Forwarding everything and hoping the destination filters later creates unnecessary traffic, cost, and operational noise.

The EventBridge mistake that can keep triggering itself

Event-driven automation can create feedback loops.

Suppose a rule reacts to a certain resource change. Its Lambda target modifies that same resource. The modification generates another event matching the same rule. The Lambda runs again. Its change creates another event.

You now own a very efficient machine for doing the same unnecessary thing repeatedly.

This is not fixed by increasing retry settings.

The rule needs a pattern that distinguishes the condition requiring action from the state your action produces.

Alarm automation has a similar design lesson. If a Lambda changes something that causes the monitored signal to move, decide deliberately whether the resulting alarm transitions should trigger the same automation again.

When EventBridge is not the best answer

EventBridge is useful enough that it becomes tempting to put it in every architecture.

Do not.

If a CloudWatch alarm's direct action already does exactly what you need, adding a routing layer may not buy you anything.

If the real requirement is durable buffering for a worker, SQS may be the central service.

If the real requirement is straightforward publish/subscribe notification, SNS may be enough.

If you have one supported streaming or messaging source, one target, and optional filtering or enrichment, EventBridge Pipes may be the simpler shape.

If the trigger is a clock rather than an event, EventBridge Scheduler is designed for that problem.

Use EventBridge when event routing is actually useful: several sources, several consumers, selective filtering, cross-account routing, AWS service events, transformations, or the need to add and change consumers without rewriting the producer.

Ethan's opinion is simple: “A service belongs in the diagram because it owns a job, not because its icon makes the diagram look more cloud-native.”

When nothing works: what to gather before escalating

If you reach the point where the obvious fixes do not explain the failure, gather the route instead of collecting screenshots at random.

Record:

• AWS account ID involved in the source and target.
• Region.
• event bus name.
• rule name and ARN.
• complete event pattern.
• an example event you expect to match.
• target ARN.
• target permission mechanism.
• execution role ARN when one is configured.
• retry policy.
• DLQ ARN.
• timestamps for the failed attempt.
• FailedInvocations and DLQ-related metrics around that time.
• target logs or metrics covering the same window.

For a cross-account path, collect both sides of the permission story.

For an SNS or SQS target using customer-managed KMS encryption, include the encryption and key-policy path in your review instead of checking only the topic or queue policy.

For an execution role, check both halves: can EventBridge assume the role, and does the role have permission to perform the target action?

The goal is to identify the first broken link.

If the event was never produced, target permissions are irrelevant.

If the event matched and invocation failed, rewriting the event pattern is irrelevant.

If EventBridge successfully invoked Lambda and the function threw an application error, EventBridge routing may already have completed its job.

A support case is much easier to reason about when you can say, “CloudWatch changed state at this timestamp, this exact event should match this pattern, the rule recorded an invocation, and delivery failed to this target ARN.”

That is an incident description. “EventBridge not working” is only a mood.

16 EventBridge questions people ask after building alarms

What is Amazon EventBridge in simple words?

EventBridge is a serverless event-routing service. A source produces an event, EventBridge receives it, filtering decides whether the event matters, and a target or subscriber receives the matching event.

Does every CloudWatch alarm need EventBridge?

No. CloudWatch alarms support direct actions for several use cases. EventBridge is useful when you want event routing, filtering, multiple independent consumers, transformations, cross-account patterns, or a broader event-driven workflow.

Does CloudWatch send alarm state changes to EventBridge automatically?

Yes. CloudWatch sends alarm state-change events to EventBridge, and CloudWatch guarantees delivery of those alarm state-change events.

What EventBridge event pattern matches a CloudWatch alarm?

Start with source aws.cloudwatch and detail type CloudWatch Alarm State Change. Add detail.state.value when you want only ALARM, OK, or another state, and add the alarm name when the rule should match one alarm.

Why is my EventBridge rule not triggering when the alarm is already in ALARM?

A state-change event occurs when the alarm transitions. Remaining in ALARM is not a new state transition every minute. Confirm that a new transition occurred after your rule was ready.

Why does my EventBridge rule match but Lambda does not run?

Check target delivery and permissions. EventBridge can have a correct pattern and still be unable to invoke the target. Also inspect FailedInvocations, the Lambda permission or execution role, and the function's own logs.

Can EventBridge send a CloudWatch alarm to SNS?

Yes. An SNS topic can be the target of a Classic EventBridge rule. EventBridge needs permission to publish to the topic through the configured permission mechanism.

Can EventBridge send CloudWatch alarm events to SQS?

Yes. An SQS queue can be an EventBridge rule target. This is useful when you want the event filtered by EventBridge but processed later by a queue consumer.

What is the difference between EventBridge and SNS?

EventBridge focuses on event ingestion, filtering, transformation, and routing. SNS is a publish/subscribe messaging service. They can work together, with EventBridge selecting an event and SNS distributing a resulting notification to subscribers.

What is the difference between EventBridge and SQS?

EventBridge routes matching events. SQS stores messages in a queue so consumers can process them asynchronously. Use them together when you want EventBridge filtering followed by queue buffering.

Does EventBridge retry failed rule targets?

Yes. For Classic rule target delivery, the default maximum event age is 24 hours and the default maximum retry-attempt value is 185. You can configure the retry policy for the target.

What happens when EventBridge retries are exhausted?

If you configured a dead-letter queue for the rule target, EventBridge can send the failed event there after it can no longer deliver it under the retry policy. The DLQ gives you a preserved failure to inspect.

How many targets can one EventBridge rule have?

A Classic EventBridge rule can have up to five targets. The target-per-rule quota is not adjustable. Using separate rules for independent consumers can make maintenance easier even though multiple targets are supported.

Should CloudWatch alarm events use the default EventBridge bus?

Normal AWS service events sent to EventBridge arrive on the default event bus. For a direct CloudWatch alarm state-change rule, that is the bus you normally start with.

What changed with EventBridge Custom event buses in September 2026?

On September 24, 2026, EventBridge launched an enhanced Custom Event Bus with subscriber-based consumption, event retention, ordering capabilities, and a new data-volume pricing model. The previous custom event-bus experience is now called Custom Event Bus - Classic.

How do I troubleshoot EventBridge when nothing is working?

Trace the path in order: source event, Region, event bus, event pattern, rule state, target configuration, target permissions, EventBridge delivery metrics, target logs, and DLQ. Find the first point where the observed behavior stops matching the architecture.

The EventBridge diagram I want you to remember

CloudWatch and EventBridge stop feeling like overlapping AWS products when you give each one a job.

Metric / condition
       |
       v
CloudWatch Alarm
detects a state change
       |
       v
CloudWatch emits
Alarm State Change event
       |
       v
EventBridge default bus
receives the event
       |
       v
Rule filters it
       |
       v
Target delivery
       |
  +----+-----+
  |    |     |
Lambda SNS  SQS
  |
  v
automation

If the diagram fails, trace it from the top.

Did CloudWatch actually change state?

Did the event arrive where your rule is listening?

Does the event match the pattern?

Is the rule enabled?

Is the target attached?

Does EventBridge have permission to deliver to it?

Did delivery fail and move toward retries or the DLQ?

Did the target receive the event and then fail inside its own application logic?

Those questions turn EventBridge from “AWS magic” into wiring you can inspect one connection at a time. If your next alarm turns red and the automation stays silent, start with the first broken link rather than rebuilding the whole board.

Revision note. Written October 5, 2026, after the enhanced Custom event bus arrived and the older one became Classic. When an alarm turns red and nothing moves, the wiring is usually fine except for one connection, and that one can be found.