Cost Visibility in the Developer Portal: Per-Service (2026)

Q: Why does a cloud cost dashboard fail to reduce spend even when it is accurate?

Because accuracy and influence are different properties, and dashboards optimise for the first. The cloud provider console is correct to the cent and organised by account, region and SKU, which is how the provider bills rather than how engineers build. A finance dashboard aggregates that into cost centres, which is how the organisation budgets. Neither is expressed in the unit an engineer owns, which is a service with a repository, a team and an on-call rotation, and neither is in the place an engineer works. The engineer deciding whether a new service gets a dedicated database or a schema on the shared one never sees either surface, so the decision is made without the number. Cost visibility only changes behaviour when the number arrives where the decision is made, in the unit the decider owns, while the decision is still open, which in a platform-engineering organisation means the service page in the developer portal and the template the service is scaffolded from.

Q: What is FOCUS and why does it matter for a per-service cost pipeline?

FOCUS is the FinOps Open Cost and Usage Specification, an open standard for the columns and semantics of cloud billing data maintained under the Linux Foundation's Joint Development Foundation, with v1.4 the current published release as of September 2026. It matters because a per-service pipeline has to join spend from every provider and, increasingly, from SaaS and data platforms, and before FOCUS each provider's billing export had its own column names, cost definitions and treatment of discounts and amortisation. With providers shipping FOCUS-format data natively, AWS Data Exports offering FOCUS 1.2 and 1.0 tables, Microsoft Cost Management publishing a FOCUS cost and usage file, and Snowflake, Databricks, MongoDB and Vercel among the non-hyperscalers listed on the FOCUS adoption page, the normalisation stage of the pipeline becomes a load rather than a translation project, and columns such as BilledCost, EffectiveCost, ServiceName and ResourceId mean the same thing across sources.

Q: How do you allocate shared Kubernetes cluster cost, including idle capacity, to individual services?

With a tool such as OpenCost or Kubecost for the mechanics and a written policy for the judgement calls. The tool splits node cost to workloads by requested and used CPU, memory and storage, aggregated by namespace, label or controller, which is measurement. What remains is idle capacity that no workload requested and shared system namespaces such as ingress, monitoring and the mesh, and how those are allocated is policy, not measurement. Two defensible policies exist: allocate idle and shared cost to services in proportion to their requests, which motivates service teams to right-size, or charge idle and shared cost to the platform team's own entity, which motivates the platform to fix bin-packing and reclaim nodes. On a $180,000 a month cluster with 30 percent idle and 15 percent shared, the same service can be shown $18,000 or $32,700 depending on that choice. Either is legitimate; what destroys trust is showing a team a number without telling them how much of it is a policy they cannot influence with their own code.

Q: Should cost be attributed to services through cloud resource tags or through the software catalog?

Through the catalog, with tags as one input among several. Tag-based attribution fails on the resources that cost the most: shared clusters where one tag covers many services, managed resources created by automation that never received the tag, and everything provisioned before the tagging mandate. It also duplicates ownership metadata that the catalog already holds and keeps current, because the catalog entity has an owner, a system and a lifecycle for reasons unrelated to cost. The attribution service should therefore map resources to catalog entities using tags, Kubernetes labels and account structure as evidence, let the entity carry the ownership, and report as a first-class output the percentage of spend it could not map. That unallocated bucket, owned on the platform team's scorecard and driven down over time, is a more honest and more actionable metric than a tag-compliance percentage, and it avoids the silent error of spreading unattributed spend across services so the totals add up.

Q: What does the Backstage Cost Insights plugin actually do, and what do you have to build yourself?

It renders, and you compute. The plugin, maintained in the Backstage community-plugins repository, shows daily cost per catalog entity with trends over time and comparisons against business metrics, and its stated design rationale is that engineers optimise cloud cost organically when they see it in their daily work, in software terms familiar to them, with targeted and actionable alerts. Its README is explicit that you must create a client implementing the CostInsightsApi interface, and it notes that Spotify briefly explored an AWS Cost Explorer-backed client without shipping one. Everything upstream of that interface is yours: FOCUS-normalised ingestion, Kubernetes allocation, attribution to catalog entities, the idle and shared cost policy and the per-entity store. That division is correct, because the rendering is generic and the attribution is specific to your estate, but it means the plugin is the last 10 percent of the project rather than the project, a pattern that holds for every portal, not only Backstage.

Q: When should a platform team not build per-service cost visibility?

When there is nothing to route cost to, when the spend is dominated by a few shared systems, or when the organisation is small enough that a spreadsheet works. If services are not in a catalog with owners, per-service cost has no destination, and building the catalog with ownership is the prerequisite. If two or three shared platforms account for most of the bill, a per-service view will show a dozen small numbers and one enormous platform entity and change nothing; the better investment is optimising those shared systems directly and labelling their cost as platform-imposed. If the engineering organisation is fewer than roughly thirty engineers on a bill under a few tens of thousands a month, a monthly review of the provider console beats a pipeline that costs more to run than it finds. The trigger to build is the point at which the number of services with independent cost decisions exceeds what one person can hold in their head, which in most organisations arrives together with the platform team itself.

Q: How should cost be shown at scaffold time when a new service is created from a template?

As a priced estimate of the template's defaults, displayed beside the create action, before the service exists. The defaults in a service template, such as a dedicated database instance, three environments and a minimum of two replicas per environment, commit the organisation to a floor of spend that persists until someone deletes the service, and nobody revisits defaults. Pricing those defaults from the provider price list and showing a figure of the form "approximately $1,400 a month before traffic" changes the choice at the only moment it is cheap to change. It also gives the platform team a lever it otherwise lacks: the default becomes the shared-database option and the dedicated option carries its price, so the template steers toward the cheaper architecture without a policy document. The estimate is approximate by nature and should say so; its job is not accuracy but making the cost of a default visible to the person choosing it, which is why it has the highest ratio of impact to effort of any delivery surface and is the one almost nobody builds.

Q: What is the difference between showback and chargeback, and which should come first?

Showback makes each team's cost visible to that team without moving money; chargeback bills the team's budget for it. Showback must come first, for at least two quarters, because chargeback of a number a team has never seen and cannot reconcile produces disputes rather than savings, and the disputes are usually about allocation policy rather than measurement. Before any chargeback, three things should be true: the per-service number is on the service page and in the team scorecard, the idle and shared cost policy is published and platform-imposed cost is labelled separately, and the unallocated bucket is under a target such as 10 percent of spend. Only then is it worth asking whether chargeback adds anything, and often it does not: teams that see their number beside their error budget and get an alert when the trend breaks act on it without an invoice, and the accounting overhead of internal billing is a cost of its own. Chargeback is a tool for organisations where budgets are the only lever; for most engineering organisations, routed showback is the lever.