Build AWS Health event notification rules for service disruptions, scheduled changes, and account-specific events.
Build AWS Health event notification rules for service disruptions, scheduled changes, and account-specific events.
Required Fields
NameEventPattern.sourceEventPattern.detail.serviceOutput will appear here...The builder validates that Name, EventPattern.source, and EventPattern.detail.service all resolve before accepting the JSON as a valid PutRule-plus-PutTargets request pair, the fields EventBridge needs to know the rule's name, that it matches AWS Health events, and which services it's scoped to; it can't verify the referenced SNS topic or Lambda function ARNs actually exist or that the InputTransformer's JSONPath expressions are valid against real Health event payloads.
Build an EventBridge rule matching AWS Health events (aws.health source) scoped to specific services, event categories (issue vs. scheduledChange), status codes, and eventScopeCode, routing matches to targets like SNS or a Lambda with an InputTransformer reshaping the raw event into a readable alert message. eventScopeCode matters more than it looks: ACCOUNT_SPECIFIC events are the ones actually affecting your resources, while PUBLIC events are broader AWS service health advisories not necessarily tied to anything in your account, a rule without this filter (or one incorrectly scoped) either misses account-specific issues or floods you with public health noise irrelevant to your actual footprint.
Keep the service list in EventPattern.detail.service synchronized with your actual architecture, a Health event rule is only as useful as its service scope, and it's easy to forget to add a newly-adopted service to an existing rule.
eventScopeCode ACCOUNT_SPECIFIC is almost always what you want for actionable alerting, a rule matching on PUBLIC events too can generate a meaningful amount of noise about general AWS service status unrelated to your account.
Test the InputTransformer's InputPathsMap against a real sample Health event structure before relying on it in production, a JSONPath typo produces an empty or malformed placeholder value in the resulting message rather than an obvious error.
ACCOUNT_SPECIFIC events are ones AWS has determined directly affect resources in your account (a specific EC2 instance scheduled for retirement, for instance). PUBLIC events are broader service health advisories (a general service disruption in a region) that may or may not affect your specific resources. Filtering to ACCOUNT_SPECIFIC in eventScopeCode is what makes a Health event rule actionable rather than noisy, since it's specifically about your footprint, not general AWS service status.
No, the service list acts as an allowlist filter, only events for services explicitly listed match the rule. Adding a new service to your architecture without updating this rule's service list means Health events for that new service silently won't trigger this rule at all, a common gap when infrastructure grows but the monitoring rule isn't updated alongside it.
It extracts specific fields (via JSONPath, like $.detail.service or $.detail.eventDescription[0].latestDescription) from the raw matched event into named placeholders, which InputTemplate then references (like <service>, <description>) to construct a custom-formatted message string passed to the target. Without it, the target (a Lambda function, in this case) receives the full, verbose raw event JSON instead of a concise, purpose-built message.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.