34 — Cost and FinOps Checklist#

Verify that technology spending is attributable, visible, forecastable, and optimized for business value without compromising required quality, reliability, security, or user outcomes. FinOps is a shared product, engineering, finance, and procurement practice—not simply a directive to minimize the cloud bill.

Scope: Backend / API-specific. This file is one part of the 34_Cost_and_FinOps.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Cost scope / providers / billing currency:
• Budget, forecast, and allocation policy references:
• FinOps / product / engineering / finance owners:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this reusable checklist into project-specific review records; leave the shared template unchecked.
2. Mark [x] only after verification from provider billing data, ownership metadata, cost forecasts, approved budgets, utilization measurements, unit metrics, or documented decisions. Record failed checks and genuine N/A rationales in project-specific notes or issues using their COST IDs; do not add evidence tables to this repository template.
3. Tailor controls to the technology costs that apply: cloud resources, SaaS, licenses, data platforms, vendor APIs, AI inference, or on-premises infrastructure. Not every project uses commitments, multiple providers, chargeback, or business-unit unit economics.
4. Review ## API Checks and ## Frontend Checks independently where relevant. If one surface does not exist, document N/A and why in project records.
5. Revisit cost baselines, forecasts, allocation rules, and guardrails after major demand, architecture, provider, contract, pricing, or launch changes. Review material contractual and financial decisions with qualified stakeholders.

Cost ownership and allocation#

• COST-008 Assign owners to shared infrastructure and platform services such as observability, networking, security tooling, and build systems.

Budgets and visibility#

• COST-022 Record forecast assumptions for baseline demand, launch peaks, growth, storage, data transfer, third-party APIs, and nonproduction environments.

Usage efficiency#

• COST-045 Detect idle, unattached, orphaned, and consistently underused infrastructure and remove or right-size it with owner approval.
• COST-048 Investigate overprovisioned compute, databases, containers, caches, and managed-service tiers.
• COST-051 Assess network egress, cross-region transfers, CDN misses, and repeated service-to-service calls for avoidable spend.
• COST-053 Review cache placement, cache hit rates, expiry, and invalidation to reduce repeat work without serving incorrect or private data.
• COST-058 Check that performance tuning does not shift disproportionate costs to database, storage, network, or another internal team.

Forecasting and optimization#

• COST-073 Differentiate resource efficiency from business unit economics so cheaper compute is not mistaken for improved customer value.
• COST-082 Review cost-related regressions after software, infrastructure, workload, vendor, and pricing changes.

API Checks#

• COST-087 Map critical API operations to their principal cost drivers, including compute, database I/O, storage, data transfer, and billable external calls.
• COST-088 Measure cost or resource use per representative API request or completed business transaction where feasible.
• COST-089 Define and validate request-size, response-size, pagination, and query-complexity limits for expensive endpoints.
• COST-090 Test that filters, sorting, joins, and batch endpoints do not trigger unbounded database or analytics costs.
• COST-091 Set appropriate quotas, throttling, concurrency limits, and timeouts for expensive consumer or tenant usage.
• COST-092 Use retry budgets, backoff, and idempotency so transient failures cannot multiply billable side effects.
• COST-093 Detect duplicate webhooks, scheduled tasks, and message redeliveries that could double-bill downstream provider requests.
• COST-094 Capture third-party API consumption and applicable usage tiers, price units, quotas, and overage policies.
• COST-095 Use approved cost guardrails for AI inference or other metered APIs, such as token, context, payload, or call budgets, where relevant.
• COST-096 Identify and control excessive fan-out, N+1 requests, and repeated downstream calls across a single logical operation.
• COST-097 Review cache eligibility and per-tenant isolation for GET/read responses that can safely avoid repeated work.
• COST-098 Monitor error, timeout, and canceled-request costs so failed operations are not invisible in unit economics.
• COST-099 Ensure async job APIs expose status and cancellation to prevent redundant polling and duplicate submissions.
• COST-100 Attribute API usage to an appropriate service, product, or tenant without exposing customer-identifying labels in high-cardinality telemetry.
• COST-101 Distinguish real customer usage from tests, monitoring probes, load generation, and internal automation in cost analysis.
• COST-102 Set usage anomaly alerts for clients, keys, routes, tenants, or vendors with financially material spend exposure.
• COST-103 Review authorization and rate limits so unauthorized or abusive requests cannot trigger unlimited cost.
• COST-104 Make cost-affecting API contract changes, new metered fields, or third-party dependencies visible during release review.
• COST-105 Verify safe behavior when a billing-related quota is reached, including appropriate errors and recovery guidance.
• COST-106 Confirm API cost optimizations preserve response correctness, availability objectives, and compatibility guarantees.

Release gate#

• The release has named product, engineering, and financial owners for its material technology costs, with an approved allocation approach for shared and direct costs.
• Budget, baseline, forecast, principal assumptions, and potential cost-impacting launch or growth scenarios are documented at an appropriate level of detail.
• Critical spending and usage reports reconcile to trusted provider or financial data within accepted tolerances, and material unallocated charges are explained or assigned for investigation.
• Budget threshold, unusual-spend, and quota alerts or equivalent guardrails have owners and a tested escalation route appropriate to release risk.
• Significant compute, storage, data-transfer, SaaS, API, and frontend cost drivers are reviewed for avoidable use without undermining performance, accessibility, security, or reliability commitments.
• Applicable API and frontend operations have controls against unbounded or duplicate billable actions, with appropriate behavior when quotas or limits are reached.
• Any material over-budget forecast, unaffordable unit economics, unapproved commitment, or other significant cost risk has an explicit authorized disposition and remediation owner.

Domain-specific approval rule: Block cost readiness approval if material spend is unowned and invisible, foreseeable high-impact cost exposure lacks acceptable bounds, or a required budget/contract approval is missing. Meeting a cost target does not justify bypassing legal, security, quality, accessibility, or reliability requirements.

Trusted references and scope#

These review questions are informed by the following primary FinOps and architectural guidance. Source recommendations are not universal compliance obligations; adapt them to the workload and commercial model.

• FinOps Foundation — FinOps Framework — cross-functional technology cost accountability, value, and operating model.
• FinOps Foundation — Allocation — cost ownership, tagging and hierarchy, shared cost treatment, and allocation coverage.
• FinOps Foundation — Anomaly Management — detection, routing, investigation, and resolution of unplanned spend.
• FinOps Foundation — Forecasting — forecast models, business drivers, scenarios, and variance tracking.
• FinOps Foundation — Unit Economics — aligning technology unit costs to product/business outcomes.
• FOCUS — FinOps Open Cost and Usage Specification 1.3 — standardized billing vocabulary and cost/usage data when compatible datasets are used.
• FOCUS — Cost and Usage dataset — distinct billed, effective, contracted, and list cost fields; billing period and metadata.
• Microsoft Azure Well-Architected — Cost Optimization checklist — financial responsibility, budgets, guardrails, unit cost, utilization, optimization, and trade-offs.
• Microsoft Azure Well-Architected — Cost Optimization — usage, rate, and continuous optimization principles.

Applicability: FOCUS 1.3 provides a published data specification, not an assertion that every provider export is FOCUS 1.3-compatible or that 1.3 is the newest version. Cloud-specific rate models and tagging practices do not apply unchanged to every SaaS, AI, data center, or on-premises product. Account for billing delays, discounts, currency, shared services, and business value before claiming realized savings.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: usage tagging, budget alerts, cost estimates, and anomaly scenarios; include API and service behavior where applicable.
• Cross-stack: Infracost.
• Python: Cloud Custodian + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• cost-optimization — Review resource costs and attribution (wshobson/agents, 42,437 repo stars).
• cost-analysis — Review Azure cost data when applicable (microsoft/skills, 3,198 repo stars).
• aws-cost-optimize — Review AWS spending where applicable (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.