Skip to content

fix(cost-optimization): improve monthly cost estimation and prevent d… - #164

Open
ankit3890 wants to merge 1 commit into
NEXARA-oss:mainfrom
ankit3890:patch-1
Open

fix(cost-optimization): improve monthly cost estimation and prevent d…#164
ankit3890 wants to merge 1 commit into
NEXARA-oss:mainfrom
ankit3890:patch-1

Conversation

@ankit3890

Copy link
Copy Markdown

Summary

Fixes an incorrect monthly cost projection in CostOptimizationAnalyzer and adds a defensive guard against a potential divide-by-zero.

Problem

estimateMonthlyCost() previously calculated:

(totalCost / executionCount) * 30

This assumes executions occur at a steady rate (~1/day), which isn't true for most workflows—especially idle ones. Since detectIdleResources() uses this value to populate IdleResource.estimatedMonthlyCost, it could significantly overestimate the savings reported by terminate_idle recommendations.

Example

  • 2 executions at $1 each over the course of a year
  • Previous estimate: $30/month
  • Actual recent spend: $2/month (or $0/month if no executions occurred in the last 30 days)

As a result, long-idle or low-volume workflows could report inflated monthly savings.

Fix

  • Updated estimateMonthlyCost() to calculate monthly cost by summing the actual cost of executions within the trailing 30-day window.
  • Added an explicit guard when calculating avgCostPerExecution to safely handle potential divide-by-zero scenarios during future refactors.

Impact

  • More accurate IdleResource.estimatedMonthlyCost.
  • More realistic terminate_idle recommendation savings.
  • estimatedTotalMonthlySavings now better reflects actual recent usage.
  • No changes to exported types, public APIs, or method signatures.

Notes for Reviewers

estimateMonthlyCost() filters executions using created_at, while idle detection uses updated_at. This is intentional, as monthly cost should reflect when an execution occurred, whereas idleness is determined by the resource's latest activity.

Performance & Observability Impact

Performance

  • Preserves the existing O(n) time complexity.
  • Adds only a lightweight date comparison while aggregating execution costs.
  • No changes to database queries, memory usage, or algorithmic complexity.

Observability

  • No new metrics, logs, trace spans, or telemetry have been added.
  • No changes to existing monitoring or observability behavior.

User Impact

  • Monthly cost estimates are now more accurate for idle and low-volume workflows.
  • Cost-saving recommendations better reflect actual recent spending.

…ivision by zero

## Summary

Fixes an incorrect monthly cost projection in `CostOptimizationAnalyzer` and adds a defensive guard against a potential divide-by-zero.

## Problem

`estimateMonthlyCost()` previously calculated:

```ts
(totalCost / executionCount) * 30
```

This assumes executions occur at a steady rate (~1/day), which isn't true for most workflows—especially idle ones. Since `detectIdleResources()` uses this value to populate `IdleResource.estimatedMonthlyCost`, it could significantly overestimate the savings reported by `terminate_idle` recommendations.

### Example

- **2 executions** at **$1 each** over the course of a year
- **Previous estimate:** `$30/month`
- **Actual recent spend:** `$2/month` (or `$0/month` if no executions occurred in the last 30 days)

As a result, long-idle or low-volume workflows could report inflated monthly savings.

## Fix

- Updated `estimateMonthlyCost()` to sum the actual cost of executions within the trailing **30-day window** instead of extrapolating from lifetime averages.
- Added an explicit guard when calculating `avgCostPerExecution` to safely handle potential divide-by-zero scenarios during future refactors.

## Impact

- More accurate `IdleResource.estimatedMonthlyCost`.
- More realistic `terminate_idle` recommendation savings.
- `estimatedTotalMonthlySavings` now better reflects actual recent usage.
- No API, type, or method signature changes.

## Testing

- [ ] Verify sparse historical executions no longer produce inflated monthly costs.
- [ ] Verify workflows with recent executions report actual 30-day spend.
- [ ] Confirm empty execution datasets still return an efficiency score of **100** (regression check).

## Notes for Reviewers

`estimateMonthlyCost()` filters using `created_at`, while idle detection uses `updated_at`. This is intentional, as cost should reflect **when an execution occurred** rather than its latest update time. Happy to align these semantics if a different interpretation is preferred.
Copilot AI review requested due to automatic review settings July 24, 2026 16:52

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants