The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 15, 2026 10:58pm

PR Summary

Medium Risk
Changes the semantics and API contract of alarm muting from toggling alarm actions to creating/deleting named mute rules with schedules; mistakes could leave alarms muted longer than intended or fail to unmute if rule names don’t match.

Overview
Updates CloudWatch alarm muting to use CloudWatch alarm mute rules instead of enabling/disabling alarm actions. mute-alarm now creates a named rule via PutAlarmMuteRule with a scheduled start (at(...)) and ISO-8601 duration (validated and capped at 15 days), and returns the rule name plus the computed schedule details.

unmute-alarm now deletes the mute rule by muteRuleName via DeleteAlarmMuteRule, and the UI/tool contracts are updated accordingly (new required muteRuleName, new mute-only durationValue/durationUnit and optional description/start date; unmute no longer takes alarm names).

^{Reviewed by Cursor Bugbot for commit 7974bef. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

This PR replaces the previous DisableAlarmActions/EnableAlarmActions approach with CloudWatch's newer PutAlarmMuteRule/DeleteAlarmMuteRule APIs, so mutes now carry an explicit time window and auto-expire rather than requiring a manual re-enable. The changes span the route handlers, Zod contracts, block definition, tool configs, and TypeScript types consistently.

• Mute route: builds a Schedule.Expression using an at() one-time expression and an ISO-8601 duration, with a 15-day cap enforced in the Zod schema via superRefine.
• Unmute route: simply deletes the named mute rule, replacing the previous alarm-list-based approach.
• Block: adds muteRuleName, durationValue, durationUnit, and optional description/startDate inputs; splits the previously shared mute/unmute case into two separate branches.

Confidence Score: 3/5

The mute route has two issues that could prevent mute rules from ever activating: a missing seconds component in the schedule expression and a potential timing conflict when a user-supplied startDate is passed as both the at() trigger and the rule's StartDate field.

The at() expression built by toAtExpression omits the seconds field — AWS docs require at(yyyy-mm-ddThh:mm:ss) — likely causing every mute-rule creation to be rejected by the CloudWatch API. Additionally, when a user provides a startDate, the code sets both Schedule.Expression = at(startDate) and StartDate = startDate to the same instant; because StartDate means the rule only takes effect after that point, the at() trigger may fire before the rule is considered active, silently producing a no-op.

apps/sim/app/api/tools/cloudwatch/mute-alarm/route.ts — both the expression format and the StartDate logic need attention before this is production-safe.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Block as CloudWatch Block
    participant Route as /api/tools/cloudwatch/mute-alarm
    participant CW as AWS CloudWatch

    Block->>Route: "POST {muteRuleName, alarmNames, durationValue, durationUnit, startDate?}"
    Route->>Route: Zod validate (incl. 15-day cap)
    Route->>Route: toAtExpression(startDate ?? now) → at(YYYY-MM-DDThh:mm)
    Route->>Route: toIsoDuration(value, unit) → PTxH / PxD / PTxM
    Route->>CW: "PutAlarmMuteRuleCommand {Name, Rule.Schedule, MuteTargets, StartDate?}"
    CW-->>Route: 200 OK
    Route-->>Block: "{success, muteRuleName, alarmNames, expression, duration}"

    Note over Block,Route: Unmute flow
    Block->>Route: "POST {muteRuleName}"
    Route->>CW: "DeleteAlarmMuteRuleCommand {AlarmMuteRuleName}"
    CW-->>Route: 200 OK
    Route-->>Block: "{success, muteRuleName}"

_{Reviews (1): Last reviewed commit: "fix(cloudwatch): use PutAlarmMuteRule fo..." | Re-trigger Greptile}