"Detect and act": what CDCR means

Outcome

By the end of this lesson, you will be able to define CDCR, distinguish it from the report-and-ticket pattern, and articulate why “act” is the differentiator.

1. Concept

CDCR stands for Continuous Detect, Continuous Remediation. Remediation is the word for actually fixing the thing, as opposed to writing it down.

Most cost work is a project: somebody runs an exercise, finds waste, and the estate drifts back over the following quarter. CDCR treats it as a loop that never stops. The system keeps looking for waste, sorts each finding by how safe it is to act on, and acts within minutes or hours rather than weeks.

That loop is what this University is built around. Everything else in the curriculum is the working knowledge you need to run it.

The legacy pattern: report and ticket

The pattern CDCR replaces is older than cloud. Call it report-and-ticket:

1. A tool detects waste (idle EC2, oversized RDS, orphaned EBS)
2. The tool surfaces it in a report or dashboard
3. A human reads the report (days later, typically)
4. The human files a Jira ticket
5. The ticket waits in a backlog (weeks)
6. An engineer eventually picks up the ticket
7. The engineer makes the change in production (manual, error-prone)
8. The savings finally land
9. Loop back to step 1: but now the waste has accumulated for weeks

Every step is friction. Only the first one is fast: detection happens daily at worst. Steps 2 through 8 routinely take 30 days or more, and even a strong FinOps team lands somewhere between four and eight weeks per finding.

The waste accumulates throughout. A $500/month idle EC2 instance found on day 1 and remediated on day 45 has burned $750 of avoidable spend in the interim. Multiply by hundreds of findings in a typical estate and the structural waste is substantial.

The CDCR pattern

CDCR replaces the workflow:

1. Continuous discovery: the system polls and detects every few hours
2. Continuous classification: each finding is tagged by safety category
                              (safe-to-auto / safe-with-approval / human-only)
3. Continuous remediation: safe findings remediate automatically
                            with-approval findings raise a request
                            human-only findings get an actionable alert
4. Continuous verification: the action's effect is confirmed in billing
5. Loop continues, no human in the critical path for safe findings

The time-to-remediation drops from weeks to hours or minutes. The avoidable waste between detection and remediation shrinks to near-zero on the safe class.

What “continuous” means specifically

LOOKING FOR RESOURCES     every 6 hours, and on demand when you ask
RE-SCORING FINDINGS       every time it looks
ACTING ON A SAFE FINDING  under 30 minutes from spotting it
ACTING ON AN APPROVAL     usually within 24 hours, since a person has to say yes
SPOTTING A COST SPIKE     15 minutes

Every one of those is short enough that the loop closes inside the same working day. No multi-week backlog, and no “I’ll get to it next sprint”.

What “act” means specifically

Acting is not one big red button. How much the system may do on its own depends on what the finding is:

SAFETY CLASS                  ACT MODE
─────────────────────────────────────────────────────────────
Idle / orphan / scheduled     Auto (within scope and rate limits)
Right-sizing                  Approval-gated (admin sign-off)
Database / stateful changes   Never auto: human-only with playbook
Recommendations                Always shown: auto-remediation is opt-in

The system can act, and it does not act recklessly. You choose what to hand over, one class at a time. For most changes the default is that somebody has to approve, not that it happens by itself. L3 covers exactly how that is enforced.

Why acting is the part that is hard to copy

The market for cost reporting is crowded. Vantage, CloudHealth, Apptio, CloudZero and Flexera all show you where the money went. What separates them is whether anything is ever done about it.

CDCR is the practice that closes the gap between the report and the action. Here is how the field looked when this was written, taken from the Competition Parity research:

TOOL CATEGORY         DETECT  TICKET  ACT
─────────────────────────────────────────
CloudHealth            Y        Y      N
Flexera                Y        Y      N
Vantage                Y        Y      N
CloudZero              Y        Y      N
Apptio                 Y        Y      N
─────────────────────────────────────────
ZopNight               Y        Y      Y     ← the differentiator
─────────────────────────────────────────
CAST AI (K8s only)     Y        N      Y     ← act-only, narrow scope
Spot.io (K8s + VM)     Y        N      Y     ← act-only, narrow scope

This table uses ZopNight’s own definition of “act”: general-purpose, cross-cloud, closed-loop remediation. It is a point-in-time view, and the boundaries are ours, not an industry standard: several of these tools do have remediation surfaces, just narrower or differently scoped (the CAST AI and Spot.io rows are examples of act-only but narrow-scope tools). Treat the table as ZopNight’s framing of the category, not a neutral scorecard, and check the current parity research before quoting it to a customer.

The underlying CDCR claim still holds: a tool that closes the loop saves more, faster, with less human friction, than one that surfaces the same data without acting.

Five things CDCR makes possible

1. Fixes land in hours, not weeks. This is the number that matters.
2. Savings compound. Each closed loop makes the next finding easier to see.
3. Better commitment decisions. A steady loop shows you how low your usage really goes, which is what a commitment has to be sized against (M0.3 L4).
4. Engineering time goes back to engineering. Nobody spends their week triaging cost tickets.
5. Ownership follows visibility. When a team watches the loop close in front of them, caring about the cost stops being something you have to ask for.

2. Demo

A real (anonymized) detect-and-act loop in a customer estate:

T+0 min   Discovery cron runs, sees i-0xyz123 stopped for >30 days
T+1 min   Recommendation engine fires: RC-001 (Idle EC2), severity medium
          Resource is tagged environment=dev, no override, no DB attachment
T+1 min   Classification: safe-to-auto (idle, non-prod, no dependencies)
T+2 min   Customer's Auto-Remediation toggle is ON for RC-001 in dev
T+3 min   Action: terminate EC2, terminate attached EBS, snapshot first
T+5 min   Verify: state confirmed terminated, billing record drops to $0
T+5 min   Notification: Slack post to #finops-loop with savings claim
T+24 hr   Billing sync confirms the saved hours
T+24 hr   Realized savings: $34.10 (rack rate of avoided EC2 + EBS hours)

Five minutes from detection to remediation. Twenty-four hours from start to verified savings. No human ticket, no waiting, no backlog.

For approval-gated rules (rightsizing, anything destructive), the same loop with an extra step:

T+0       Detection
T+5 min   Classification: safe-with-approval (rightsizing prod DB)
T+5 min   Approval request sent to designated admin via Slack DM
T+4 hr    Admin approves. Four hours is typical; people are slower than code
T+4:05    Action executes
T+24 hr   Billing sync confirms saved hours

Four hours from spotting it to fixing it. Slower than the automatic path, and still about ten times faster than report-and-ticket, which would have taken four to six weeks.

3. Hands-on (5 min)

Walk your own current FinOps process against the CDCR loop:

1. Time from detection to surfacing in a report:
   __________ (target: hours)

2. Time from surfacing to engineering ticket:
   __________ (target: hours)

3. Time from ticket to remediation:
   __________ (target: hours; current state: weeks)

4. Time from remediation to verified savings:
   __________ (target: 24-48 hours via billing sync)

5. TOTAL CURRENT TIME-TO-REMEDIATION: ____________
   TARGET WITH CDCR: < 24 hours for safe, < 1 week for approval-gated

The gap between current and target is the structural waste the CDCR model removes.

Ask for it instead. The same task you just did in the console, asked in one sentence.

BEFORE  A ZopNight account with one cloud connected. Discovery finished, so there is something to recommend on.
ASK     "Summarise our open recommendations: how many, what severity, what they would save."
CHECK   that detect is already solved for you. The rest of CDCR is what happens after this answer.

Tools behind it: get_recommendation_summary (read, Optimize), count_recommendations (read, Cost), get_recommendations (read, Optimize). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

CDCR most accurately stands for:

A. Continuous Distribution and Continuous Replication, which is a data-platform term rather than a cost management one
B. Continuous Detect, Continuous Remediation: the operating model where waste is not just reported but acted on continuously
C. Cloud Detection / Cloud Response
D. Custom Detection, Custom Reporting

Q2

The fundamental difference between CDCR and report-and-ticket is:

A. CDCR uses newer tools
B. CDCR is cheaper to license
C. CDCR is fully automated whereas report-and-ticket is entirely manual, and nothing else separates the two of them
D. CDCR closes the loop within hours instead of weeks by removing the human ticket / backlog steps from safe-to-act remediations

Q3

“CDCR auto-remediates everything by default” is most accurately:

A. True
B. True for prod, false for dev
C. False
D. True only for compute

5. Apply

ZopNight’s product surface implements CDCR throughout:

• Discovery → Recommendations → Auto-Remediation is the loop
• Schedules → Cron Execution is the same loop for scheduling
• Anomaly Detection → Alert → Root Cause is the same loop for spikes
• Auto-Remediation toggle (per-rule, per-org) lets customers opt in to auto-remediation for safe rules
• Approval gate is configurable per rule; admin sign-off for destructive ops

The USE-CASES.md §7 (Recommendations) and §11 (Reliability) capture the contract: detect, classify, act within scope.

Related lessons

• L2: The cost of detect-only (next)
• L3: Read-only safety
• L4: What CDCR is NOT
• T2.M2.3: Auto-remediation

Glossary terms touched

CDCR · Report-and-ticket · Time-to-remediation · Safe-to-auto · Graduated authority