Lesson 6 · Extension track · four settings that decide how New Relic cuts time, and how rarely they are touched
Prerequisites: lessons 1 to 4.
Everything here lives in the signal block.
| Setting | Block | Controls |
|---|---|---|
aggregation_window | signal | How much data goes into one data point. |
threshold_duration | terms | How long the breach must last across successive data points. |
Window duration is about resolution. Threshold duration is about persistence. New Relic's guidance is to match the window to the data's own frequency: one minute for per-minute data, sixty minutes for hourly data.
New Relic docs, Alert conditions, "Window duration".
slide_by, or sliding window aggregationBy default, windows are adjacent. A 1200-second window produces a data point
every 1200 seconds. slide_by makes them overlap: the window keeps
its width but advances by a smaller step.
New Relic's own reasoning for it, quoted in structure:
Start with a large aggregation window to smooth out the noise. Then avoid lag with a smaller sliding window, so you do not wait for the entire interval to elapse before checking thresholds.
New Relic docs, Alert conditions, "Use sliding window aggregation".
You get the statistical stability of a wide window with the detection latency of a narrow one. The cost is more evaluations and correlated data points.
aggregationWindow: 1200 slideBy: 60 threshold: CRITICAL ABOVE 15, duration 1200, AT_LEAST_ONCE
[SHIPMENT] Canada Post Carrier Integration Error Rate (tf) (id 65685767, policy Carrier Monitoring). Live and enabled.
Read what those three lines do together. Each data point averages 20 minutes
of Canada Post traffic, which comfortably clears the condition's 50-event floor
even at the overnight trough. A new data point arrives every 60 seconds instead
of every 20 minutes. And because AT_LEAST_ONCE now sees twenty
overlapping windows inside its 1200-second duration rather than one, it becomes
a genuinely different rule.
Lesson 2 left an
unresolved tension: a wide window clears the volume floor overnight, but a wide
window detects slowly. slide_by is how you get both. It is the
single most useful setting in this lesson, and only 62 of the 1000 sampled live
conditions use it, and 29 of those come from Terraform.
aggregation_method: when is a window finished?The Shippo module documents this precisely:
Determines when we consider an aggregation window to be complete so that we can evaluate the signal for incidents.
shippo-tf-services/modules/newrelic-alert/README.md
Three values, and Shippo's usage is lopsided.
| Value | Live conditions (of 1000) | Terraform call sites |
|---|---|---|
event_flow | 904 | 353 |
event_timer | 87 | 43 |
cadence | 9 | 9 |
event_flow is the default and the right answer for a steady
stream. CARRIER_INTEGRATION_RESPONSE runs at roughly 2 to 3.6
million events per hour, so windows close promptly and predictably.
event_timer exists for sparse or bursty signals where waiting on
the arrival of newer data would stall evaluation indefinitely.
cadence is the oldest mechanism and the nine call sites are all the
same nine live conditions, so nothing has drifted there.
Check the accepted values and their precise timing semantics in the provider documentation before changing one. The Shippo module applies no validation, so a typo becomes an API error at apply time rather than a plan failure.
aggregation_delay and aggregation_timerThese are the buffer against late-arriving data. New Relic describes the purpose plainly:
The selected delay setting introduces a waiting period before the alert condition assesses data against defined thresholds. This buffer allows time for data discrepancies to settle, reducing the likelihood of misleading alerts.
New Relic docs, Alert conditions, "Fine-tune advanced signal settings".
The sizing rule from the same source: if data points consistently arrive with timestamps inside a single minute, a low delay is enough. If timestamps span several minutes in either direction, raise it.
The two arguments are alternatives, not companions.
aggregation_delay pairs with event_flow and
cadence. aggregation_timer pairs with
event_timer. Shippo's live values are conservative and consistent:
60 seconds on 65685767, 120 seconds on 63897179 and
61106123.
evaluation_delay, a different thing entirelyNot a per-window buffer. It delays when the condition starts evaluating at all, measured from the point the signal appears. Its use is a signal that is known to be wrong immediately after it starts: a service warming up, a cache filling, a deploy settling.
Used on 35 of the 1000 sampled live conditions, and 19 Terraform call sites.
Three of the four [CCAP] FedEx REST Rating conditions set it to 60
seconds. The 4xx one leaves it null, which is the kind of inconsistency a
four-condition set accumulates when each is edited on its own.
A static condition can be told to extrapolate. New Relic analyses the recent trend and opens an alert for a threshold it predicts you will breach, before you breach it. The look-ahead is capped at 360 times the window duration, and you choose what happens when the real signal catches up: close the predicted event and open a real one, or keep the predicted event open to reduce noise.
New Relic docs, Alert conditions, "Predictive alerts with static thresholds".
Nothing in shippo-tf-services enables it. It is a plausible fit
for slow-filling resources such as queue depth, disk, or a rate-limit budget. It
is a poor fit for carrier error rates, which step rather than trend.
One line from the vendor documentation is worth memorising, because it contradicts the obvious reading:
Anomaly thresholds: the gap-filling value is interpreted as the number of standard deviations.
New Relic docs, Alert conditions, "Gap-filling strategy".
On a STATIC condition, fill_value = 0 means the
number zero. On a BASELINE condition, the same
fill_value = 0 means zero deviations from prediction, which
is not zero traffic. It means perfectly normal. Copying a fill setting from a
static condition to a baseline condition silently changes what it asserts.
| If you see this problem | Reach for |
|---|---|
| Wide window needed for volume, but detection is too slow | slide_by |
| Sparse signal where windows never seem to close | aggregation_method = "event_timer" |
| Alerts firing on data that arrives late and then corrects itself | Raise aggregation_delay |
| Alerts firing during warm-up right after a deploy | evaluation_delay |
| A resource that trends toward a limit rather than stepping | Predictive alerts |
1. A low-volume carrier needs a 20-minute window to clear its event floor, but 20-minute detection latency is unacceptable. What resolves this?
2. You copy fill_value 0 from a STATIC condition onto a BASELINE condition. What does that zero now assert about an empty window?
3. A condition alerts every time a service restarts, then resolves within two minutes on its own. Which setting targets that specifically?
4. Nine live conditions use aggregation_method cadence and nine Terraform call sites set it. What does that match tell you?
Primary source: New Relic docs, Alert conditions, section "Fine-tune advanced signal settings". It covers window duration, sliding windows, the delay buffer, and gap filling in one place.
Provider reference for exact argument names and accepted values:
Terraform newrelic_nrql_alert_condition.
Next: Lesson 7, auditing the policy you own. The concepts from lessons 1 to 4 turned on Carrier Capabilities (CCAP), with the findings written down as they came out.
Still unwritten, if you want them: compound alert conditions, scheduled muting rules, service levels with error budgets, and workflow enrichment. Each is a real New Relic capability absent from CCAP alerting.
Ask your teacher. Ask for a sweep of which CCAP conditions
would benefit from slide_by. The criterion is a wide window on a
facet with low trough volume, and it is answerable with one query.