A convincing interface around an unfinished engine
Cloud Cost Observability and Optimization Hub presents a familiar FinOps promise: connect Amazon Web Services, Google Cloud, and Azure, see spending together, catch surprises, and act on savings recommendations. The stack is sensible for that job. A Go API built with Gin sits behind a Next.js dashboard, PostgreSQL with TimescaleDB stores time-series costs, and Redis is intended for background work. User registration and cloud-account screens make the repository look more complete than a collection of billing scripts.
The central problem is that the interface runs ahead of the implementation. The README labels the feature set v0.1 and openly includes mock cost data, but also says the architecture is ready for real three-cloud integration. In the actual services, only AWS calls a billing API. Google Cloud and Azure each create 30 daily records with fixed service names and fixed dollar amounts. Those values can make charts move, but they cannot tell anyone what either cloud account costs.
This distinction should decide the evaluation. CCOH is a starter application for contributors, demos, and product exploration. It is not a system a finance or platform team should use to explain a bill.
AWS is real, recommendations are not
The AWS service loads a submitted access key and secret key into the AWS SDK and asks Cost Explorer for the previous 30 days. It fetches daily unblended costs grouped by service, then separately fetches a monthly service summary and writes both sets into PostgreSQL. This is genuine integration, although it is still a thin one. Regions are recorded as global, and the code does not perform resource-level utilization analysis.
Repeated ingestion also deserves caution. The current main-branch service bulk-inserts fetched records. Open pull request #26 says repeated syncs were appending duplicates because the table lacked a suitable uniqueness rule, inflating dashboard totals. That pull request changes writes to a transactional replacement and also fixes stale sync timestamps, but it remains open. Its author notes that manual synchronization is synchronous and uses a background context with no request timeout. The checked-in AWS code confirms those context calls.
The savings layer is more plainly illustrative. It processes AWS accounts only, deletes their previous recommendations, then inserts fixed examples for a t3.large instance, an r5.xlarge database, an unused volume, and an unassociated IP address. Instance identifiers, utilization, costs, and projected savings are constants. A separate method named for real recommendations contains only comments describing future EC2, CloudWatch, RDS, EBS, and address queries. The unit tests validate arithmetic and repository behavior, not the truth of an optimization model.
Multi-cloud means placeholders today
The Google Cloud service checks that a project ID exists, then writes a compute-engine row worth $25.50 for each of the past 30 days. The Azure service does the same with a compute row worth $35.75. Submitted private keys, client emails, tenant IDs, and client secrets are not used to retrieve billing data. Issue #5 explicitly requests replacement of GCP's mock records with the Cloud Billing API. There is no equivalent completed Azure path.
This is risky because sample data sits behind normal-looking account and dashboard flows. A casual user could interpret a rendered chart as synchronized spend. The README does identify mock data, but the product must make that boundary unmistakable inside the interface before real accounts are invited. The safest evaluation uses invented credentials and treats every non-AWS number as demonstration content.
Automatic freshness is missing as well. Open issue #14 asks for a daily ingestion job across active accounts. Without it, data arrives when an account is added or a manual action triggers synchronization. Issue #19 asks the dashboard to show when each provider last synced, and an open pull request implements that display. A cost dashboard without visible and dependable freshness can produce precise-looking but stale decisions.
The quick start does not run as written
The README says to copy .env.example and run make up, promising that the database, backend, and frontend will start. The Makefile has only build, backend, frontend, and test targets. Docker Compose defines PostgreSQL and Redis only. There are no backend or frontend services in that file, and no Helm chart appears in the repository tree despite the architecture section naming Helm for production.
Configuration needs manual reconciliation too. The sample environment points at a cloud_costs database with generic credentials, while Compose creates a ccoh database with a different user and password. An experienced developer can correct these values, start dependencies, run the Go service, and run Next.js separately. That is not one-command setup, and the missing documentation matters because the application handles powerful cloud credentials.
The credential model should stop a production trial. Cloud account secrets are marshalled into a JSONB field and the migration defines that column directly. The security policy recommends running privately, preferring IAM roles, encrypting credentials at rest, and performing audits, but the model does not show an encryption boundary before database persistence. AWS currently requires static credentials in this flow. Until a reviewed secret-storage design exists, do not enter keys with meaningful access.
Health and the sensible use case
The last push was July 13, 2026, about a month before this review. GitHub reported 19 combined open issues and pull requests, and there is no tagged release. Contributor pull requests in July added tests and proposed interface improvements, but several stacked changes remain open while main has not moved. The repository contains an Apache 2.0 license file, even though GitHub's license field did not return a recognized SPDX identifier.
CCOH can still be useful as a teaching codebase. Its separation of accounts, cost records, recommendations, API handlers, and provider services gives contributors clear places to replace fixtures with real integrations. The dashboard offers a visible payoff for backend work. As software to operate, however, it needs honest setup instructions, secret encryption, real GCP and Azure ingestion, measured recommendations, scheduled refreshes, trustworthy health checks, and releases. Until then, the right description is promising scaffold, not cloud-cost authority.