Skip to content
Sencai.docs

Cloud spend visibility

Two people ask about cloud cost, and they want different things. Finance wants last month’s provider spend split into buckets they can put in a report - by cost center, project, or team. Engineering wants a shortlist of instances that are bigger than the work they do. Sencai has screens for both, but they sit in different parts of the app and they are reliable in different degrees.

Here is what Sencai actually does. It pulls cost and usage data from your connected cloud providers’ own billing APIs, stores it as cost records, and attributes those records to buckets using rules that key off resource tags. It analyzes instances and suggests smaller ones. It records a spending limit and shows current spend against it.

Here is what it does not do. It does not change your provider bill, it does not resize or delete anything on the instance-sizing screens, and - the one that catches people - it does not stop spending when you cross a cap. Almost every screen below also depends on an ingestion or analysis job that your account team enables per organization, so an empty screen usually means “not turned on”, not “nothing to report”.

What this looks like in Sencai

Section titled “What this looks like in Sencai”

Start with the data, not the report. Nothing works until cost ingestion is running for your organization, and that is not a switch you can flip yourself. Connect a cloud provider first, then open Infrastructure → Cost Records (/gravity/costs) and check that numbers move day to day. The FinOps overview gives you totals and a provider breakdown; the “COGS (FOCUS v1.3)” view gives you the line items behind them, with CSV export. Cloud cost management explains where each number comes from and how stale it can be.

Fix tagging before you build allocation rules. Allocation groups spend by a tag key - the default is cost-center. Resources that do not carry that key land in an Unallocated bucket, and a large unallocated share is the usual reason a finance report gets rejected. Tag governance lives in Compliance & Audit → Inventory (/gravity/inventory), where the Tags view collects resources missing a required tag and lets you write the missing values back to the provider. See Inventory for how tag requirements are defined and enforced.

Then split the spend. Infrastructure → Cost Allocation (/gravity/costs/allocation) breaks a chosen month into buckets and shows each bucket’s amount, its share of total spend, and its top contributing services. The Allocation Rules tab is where you define the split: a provider scope, an optional resource-type filter, a split algorithm, the tag key to group on, and an effective-from date. Export the breakdown as CSV or PDF for finance. Cost allocation & savings covers the rule fields in detail.

For the engineering half, go to workload profiling first. The screen that answers “which instances are oversized” from real behavior is AI Workload Profiling (/gravity/analytics/workload-profiles). It looks at each instance’s actual CPU and memory use and its peak versus idle hours, then suggests a migration target with a confidence percentage. Its sibling screen, Right-Sizing Recommendations (/gravity/analytics/rightsizing), compares instance type names only. Read Right-sizing in full before you act on either one - the difference between them matters more than the saving figures they print.

Watch the trend, and treat anomalies as a review queue. Intelligence → Cost Forecast (/gravity/analytics/cost-forecast) projects the next three months from up to six months of your own history, and labels each projection’s confidence by how much history it had. Intelligence → Cost Anomalies (/gravity/analytics/cost-anomalies) flags a day only when two statistical checks agree, and lets you acknowledge what you have reviewed. Both are covered in Forecasting, anomalies & capacity planning.

Record a ceiling last, and know what it is. Settings → Spend Caps (/gravity/settings/spend-caps) holds a soft and a hard monthly limit for the selected organization. Creating the first cap needs the Member role or higher; changing an existing one needs Admin or Owner. Read Spend caps before you tell anyone the limit is enforced.

What will surprise you

Section titled “What will surprise you”

A spend cap is a record and an alert, not a brake. The screen describes a soft-cap email and a hard-cap block that lets safety-critical operations through, but nothing in the platform evaluates ordinary cloud spend against your cap automatically today. That means neither the alert nor the block fires on its own.

Right-Sizing Recommendations does not look at utilization. It compares your instance type against a hierarchy of type names for that provider and suggests one a step or two down. It has no idea what the instance is doing, which is why the screen labels every row’s confidence as low. Its Apply button only marks the recommendation as applied in Sencai and shows you the resize to perform yourself in your cloud console.

Three different screens can flag the same instance as a saving. The Savings list (/gravity/costs/savings), Right-Sizing Recommendations, and AI Workload Profiling are separate mechanisms with separate data. For an instance-sizing decision, AI Workload Profiling is the one to trust - it is the only one of the three that reads actual usage. Treat Right-Sizing Recommendations as a rough shortlist, and use the Savings list for the categories the other two do not cover: idle-resource cleanup, reserved-instance opportunities, storage tiers, and egress. Note that the Savings list is also the only one whose Apply can trigger a real change to your cloud infrastructure - its confirmation dialog says so - so read that dialog rather than clicking through it. Verify utilization yourself before any resize, whichever screen suggested it.

Some of these screens are not in the sidebar. Savings, Right-Sizing Recommendations, and AI Workload Profiling are reached by direct URL. If a colleague cannot find them, that is why.

Capacity Planning cannot produce data anywhere. Intelligence → Capacity Planning (/gravity/analytics/capacity-planning) forecasts infrastructure capacity rather than cost, but its underlying weekly forecast job is not available to turn on in any deployed environment. Leave it out of your plan and ask your account team about its status rather than debugging your own configuration.

“Usage-weighted” allocation is not weighted by usage. It is one of three split algorithms on an allocation rule, and it is currently processed the same way as the even split. If you need a genuinely usage-proportional split, build it from the exported cost records instead.

Totals are not currency-normalized. Each cost record carries the currency its provider reported. If you run infrastructure across providers billing in different currencies, the overview total is a same-currency roll-up, not a converted figure - which is exactly the kind of number a finance team will notice.

Scope is one organization at a time, on every screen here, and how much FinOps tooling you get differs by plan tier. See Plans for what each tier includes and sencai.space/pricing for the numbers.

What’s next

Section titled “What’s next”