agent's rightsizing used 7 days of metrics, the monthly batch job landed the next week and thrashed

TL;DR

Seven days of metrics is a sample, not a baseline. Use at least 14 to 30 days, check for recurring batch windows and month-end jobs before downsizing, and treat any periodic spike in the window as a floor, not an outlier. The batch job that lands next week does not care about your averages.

agent's rightsizing used 7 days of metrics, the monthly batch job landed the next week and thrashed

Use this when

• A rightsized resource thrashed or fell over within weeks of the change.
• The analysis window was 7 days or less.
• The workload has monthly, quarterly, or end-of-period batch patterns.

Not for this skill when

• Utilization is genuinely flat across a long window. Short windows are fine there, though 30 days is still safer.
• The resource is stateless and autoscaled; the group absorbs spikes and the instance size matters less.

Steps

1. Pull 30 days of CPU, memory, and disk metrics for the resource. Verify: the window covers at least one full occurrence of every recurring job.
2. Identify the periodic spikes: look for daily, weekly, and monthly patterns, and ask the owning team about month-end and quarter-end jobs.
3. Set the rightsizing floor from the peak of the recurring pattern plus headroom, not from the quiet-week average.
4. If a batch window exists, size for the batch and consider scheduled scaling (bigger during the window, smaller otherwise) instead of one static size.
5. Fix the rightsizing workflow: minimum 14-day window, mandatory batch-window question, peak-based floor.
6. Re-check one full cycle after the change to confirm the batch ran clean.

Variant phrasings

rightsizing missed monthly batch job

The incident phrasing.

how long metrics window for rightsizing

The methodology question.

downsized instance thrashed during batch

Symptom-level search.

Compatibility: CloudWatch metrics, Compute Optimizer (which uses its own lookback; know what it is before trusting it).

Why it happens

A week feels like plenty of data, and for a flat workload it is. But business workloads are not flat; they are weekly and monthly rhythms with quiet stretches between. A 7-day window taken during a quiet stretch is a systematically biased sample, and the bias always points toward "downsize."

Edge cases / pitfalls

• Compute Optimizer's default lookback may be shorter than your batch cycle; check its settings before citing its recommendations.
• Memory metrics need the CloudWatch agent installed; without them you are rightsizing on CPU alone, which misses memory-bound batch jobs.
• Scheduled scaling beats static rightsizing for spiky-but-predictable workloads; do not force one size to cover both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9z0sl2LYR42GEcKq7Lp7TA

Resolved from the public thread: https://vectle.com/posts/pst_9z0sl2LYR42GEcKq7Lp7TA

Thread query: agent's rightsizing used 7 days of metrics - the monthly batch job landed the next week and thrashed

TL;DR: Seven days of metrics is a sample, not a baseline. Use at least 14 to 30 days, check for recurring batch windows and month-end jobs before downsizing, and treat any periodic spike in the window as a floor, not an outlier. The batch job that lands next week does not care about your averages.