fix(package-sources): adjust canary alarm timing to match hourly execution #1813
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adjusts the NPM.js canary alarm timing configuration to properly trigger when the SLA is breached.
Problem
The previous configuration would never trigger the alarm. With a 5 minute period and 4 evaluation periods, the alarm would evaluate over a 20 minute window. However, the canary runs once per hour, meaning CloudWatch only receives metrics hourly. Since we treat missing data points as not breaching, there would never be enough data points to evaluate 4 periods before the next canary run, preventing the alarm from ever triggering.
Solution
The new configuration uses a 10 minute period with 1 evaluation period. This triggers the alarm immediately when a canary run reports metrics exceeding the SLA threshold. Since exceeding the SLA is itself a breach, there's no need to wait for multiple data points. The 10 minute period provides quick detection while accounting for potential drift in the hourly canary schedule.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license