ankra cost
Read the organisation’s cloud cost - the same figures the portal shows under Cost - for reporting and automation. Every hour Ankra prices each cluster from its node inventory at the provider list price and allocates the result to namespaces by their CPU and memory share, so each team sees the share it drives. The fleet summary rolls every priced cluster up by provider and lists the costliest clusters; a cluster read adds the component breakdown, the namespace allocation and the daily trend. The savings model reads the biggest priced clusters and proposes one lever per cluster (right-size idle capacity, reduce unallocated run rate, or an off-hours schedule for non-production) with the monthly saving each is worth. The ledger follows each approved cost change through to the saving measured seven days after it ran. Pricing settings (display currency, effective discount, network egress estimate) apply to every figure. Pass -o json (or yaml) for the full API document.ankra cost autopilot
The cost autopilot decides how much Ankra may do about cost without asking - the Autopilot view in the portal. Every environment kind (production, staging, development, preview, unknown) defaults to a tier: hands-off (every change waits for a person), scheduled, managed or ephemeral, each described by ‘ankra cost autopilot get’. A cluster takes its environment’s tier unless a person overrides it. Quiet hours are a daily window when the autopilot starts no change of its own, and its pre-notices go to a notification route or to the organisation’s default routing. An organisation that never set a policy is hands-off for every kind. Reading the policy is open to every member; changing it needs billing.manage and clusters.write (at the cluster, for an override).ankra cost autopilot clear
Remove a cluster’s override, returning it to its environment’s tierankra cost autopilot get
Show the policy (tier per environment kind, quiet hours, pre-notice route), the tiers and every cluster’s tierankra cost autopilot override
Put one cluster in a tier whatever its environment kind.--reason is the
sentence a card shows for it (3 to 500 characters). The override replaces
the cluster’s previous one and lasts until --expires-at (an RFC 3339 time) or
for --expires-in (a duration such as 72h), or with no expiry when neither is
given. ‘ankra cost autopilot clear’ returns the cluster to its environment’s
tier.
ankra cost autopilot set
Change the organisation’s autopilot policy. Only what you pass is sent, so every other part keeps its value:--default changes only the environment
kinds it names, and the quiet hours and the pre-notice route change only when
you pass them or clear them.
--default KIND=TIER may repeat. The kinds are production, staging,
development, preview and unknown; the tiers are hands-off, scheduled, managed
and ephemeral. --quiet-hours takes a daily window as START-END in 24-hour
HH:MM (an end before the start runs past midnight) and needs --timezone, an
IANA zone.
ankra cost budgets
Monthly cost budgets for the organisation, one cluster, one environment label or one application - the budgets the portal shows under Cost. Each budget carries its month as of the read: spent so far, the projected month end at the current pace, the hour it crosses the budget, and where the month lands once the changes already approved or running have landed. A budget whose scope has no priced cluster reads “unknown”, never zero, and a budget whose scope is only partly priced says how much of it is in the figures. Reading budgets is open to every member. Adding, changing and removing one needs the billing.manage permission.ankra cost budgets delete
Remove a budget (its card is no longer raised)ankra cost budgets list
List the budgets with their month: spent, projected month end, status and crossing hourankra cost budgets set
Without a budget id, add a monthly budget for one scope:--scope, --name,
--amount and --currency are required, and --notify-at and --owner are
optional (the platform notifies at 80% of the budget unless told otherwise).
A scope holds at most one budget.
With a budget id (‘ankra cost budgets list’ shows them), change that budget.
Only the flags you pass are sent; every other field keeps its value.
--clear-owner removes the owner. A budget’s scope never changes: delete it and
add one on the other scope instead.
--amount is the budget per month in the currency’s major unit (1500 or
1500.50). --scope-id names the cluster (name or id), the application (name or
id) or the environment label; an organisation budget takes none.
ankra cost cluster
A cluster’s cost estimate: totals, component breakdown, namespace allocation and readinessankra cost decisions
The decision ledger holds every cost change Ankra proposes - a right-size, a right-size ladder, an off-hours schedule, a waste cleanup - with its plan, where it stands, who decided and what running it did. A proposal is proposed until a person approves or sets it aside; an approved one runs when a person executes it (or, for one the cost autopilot approved, after its pre-notice unless it is held). A right-size ladder runs one wave at a time: each wave is its own right_size proposal under the ladder, and the next wave runs only once the last one has passed its seven-day verification. Reading is open to every member. Approving, setting aside and running need billing.manage, and running a right-size also needs clusters.write.ankra cost decisions activity
Everything that happened to a proposal, newest firstankra cost decisions approve
Approve a proposal, with an optional note (a set-aside or failed one is re-opened or retried)ankra cost decisions execute
Run an approved proposal as you: the platform dispatches the operation its kind maps to (an off-hours schedule creates the stop and start power schedules, a waste cleanup files the cloud cleanup job, a right-size ladder files and runs its next wave) and records the receipt. The answer is the proposal as the run left it: running with the operation to follow, succeeded, or failed with the receipt saying why (exit 1). A plan that deletes something no snapshot keeps (an unattached volume) runs only with written consent: pass--acknowledge-no-snapshot once you accept
that the deletion is final. Without it the platform refuses and nothing is
attempted. --min-unattached-days sets the minimum age of what a waste
cleanup deletes (the platform raises anything under 30). Neither is ever sent
unless you pass it.
A ladder whose latest wave is still running, inside its seven-day
verification or tripped by it is not run: the platform says which, and
running it again before that changes is refused the same way.
ankra cost decisions get
Show one proposal: its plan, decision, outcome, receipt and, for a ladder, its wavesankra cost decisions hold
Hold an approved proposal before it runs. A held proposal is run by nothing: not the cost autopilot, whose pre-notice links here, and not execute. It stays held until someone releases it (ankra cost decisions release) or sets it aside. Only an approved proposal can be held; any other status is refused and the proposal stays as it stands.ankra cost decisions list
List the organisation’s cost proposals, newest first. A right-size ladder’s waves sit under the ladder when it is on the same page.--status is applied by the platform (proposed, approved, held, set_aside,
running, succeeded, failed, superseded). --kind and --cluster narrow the page
the platform returned, by the proposal’s kind and by the cluster its change
is measured on; -o json returns that narrowed page. The platform serves the
newest 200 by default; --limit asks for up to 500.
A running proposal the platform could not check against its operation on this
read is marked as such: it may already have finished.
ankra cost decisions release
Return a held proposal to approved. One the cost autopilot approved itself runs on the autopilot’s next pass once its run_after has passed; one a person approved waits for someone to run it (ankra cost decisions execute). Only a held proposal can be released; any other status is refused and the proposal stays as it stands.ankra cost decisions set-aside
Decline a proposal, with your reason (an approved or held one is withdrawn before it runs)ankra cost events
Read the events that moved the organisation’s cost run rate, newest first: application releases, node-count changes, scheduled and manual stops and starts, executed cost decisions, clusters entering or leaving pricing, and resolved cloud waste. A cluster’s run rate is metered hourly, so an event’s move is how the cluster’s run rate changed between the priced hour before it and the first priced hour at least 30 minutes after it. When the event was alone in that window the move is its own. When several events share the window (a release and the scale-up it caused) the move is theirs together and each row says “shared” rather than claim a split. With no priced hour on one side the move is unknown, never zero. A coverage event’s move is coverage, not spend; a resolved finding’s is its own monthly cost. The platform’s note on an event sits under its row. A kind of event the platform could not read is named above the table: its events are missing, not quiet. The platform serves at most the newest 500.--days sets the window (at most 34; 30 when omitted). Pass -o json (or yaml)
for the full document.
ankra cost ledger
Read the organisation’s cost ledger - every cost decision that was approved, is running or has run, with the monthly saving it was expected to bring and the saving that was measured. Seven days after a change runs, Ankra compares the cluster’s run rate before the change with its run rate at day seven, both read from the cluster’s hourly cost snapshots, and records the difference as the measured saving. A negative measured figure is a measurement too: the run rate rose. A saving that could not be measured stays unknown, never zero, and the row says why: the cluster was not priced the same way on both sides of the change (coverage moved), or there was no snapshot to read. A change undone inside its window reads reverted. A right-size also carries its usage verification (in progress, passed, failed with a rollback proposed, or unverified when metrics were missing), shown under its row. The header totals cover the whole ledger even when the row list stops at the newest changes: the savings measured this calendar month (UTC), everything measured so far, and the expected saving of the changes still approved, running or verifying, which counts as saved only once it is measured. Every figure is a monthly run rate in the organisation’s display currency.ankra cost namespaces
Read how a cluster’s cost was allocated to each of its namespaces over time, from the hourly metering (the platform keeps 35 days).--days sets the window (1-35; 30 when omitted) and --granularity the bucket:
day (the default) or hour (at most 7 days; 7 when --days is omitted).
The metering runs once an hour. A bucket none of whose hours were metered is
unknown for every namespace, drawn ’·’ and never counted as zero; a namespace
missing from a metered bucket was allocated nothing there, drawn ’_’. The
header says how many buckets were metered. TOTAL sums the metered hours,
LATEST is the current (partial) bucket and PEAK the highest bucket. The trend
is drawn per namespace, scaled to its own peak, for windows of at most 48
buckets. Nothing is extrapolated: these are list-price estimates, not the bill.
The costliest 25 namespaces are listed. Pass -o json (or yaml) for every
namespace and every bucket.
ankra cost object
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost object application
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost object cluster
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost object credential
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost object namespace
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost object stack
Read what one object costs now and over the last 30 days, from the same hourly snapshots the fleet summary reads, so the object’s figure and the fleet’s agree. A cluster and a credential cost their clusters’ run rate, idle capacity included. A namespace, a stack and an application cost their namespaces’ allocations; idle capacity belongs to the cluster, so their idle share is unknown. Open cloud waste is found per cloud resource, so only a cluster and a credential carry it. Every figure the platform cannot give prints as unknown, never as zero. An object with no priced cluster behind it says why. When coverage is incomplete the monthly figure is a floor (“at least”), and the clusters that contributed nothing, or could not price a node or billed resource, are named. The trend draws one mark per UTC day, scaled to the object’s own peak day: ’·’ is a day no cluster was metered (unknown), ’_’ a metered day that cost nothing. Pass -o json (or yaml) for the projection exactly as the platform serves it.ankra cost reconcile
Set what each cloud credential’s provider billed for a month against what Ankra’s metering estimated for the same clusters. The provider’s figures are imported from its billing API (OVHcloud and UpCloud today) and stay in the provider’s own currency; the estimate is converted into it at the rate shown. Each billed line is placed on a cluster where the organisation’s own records say which (a label Ankra set, a server it provisioned, a node’s provider id, a volume’s handle). Tax and credits are reported apart, since the estimate carries neither. Nothing unknown reads as agreement. A credential no billing document was imported for is unknown, not zero; a failed import says why; a difference is stated only when the provider’s figures are final and the estimate covers every hour each named cluster existed that month, and otherwise the reason is shown. Billed lines no cluster could be placed on are counted with their amount.--month reads a UTC calendar month as YYYY-MM (the last closed month when
omitted; the running month is month to date on both sides). Pass -o json (or
yaml) for the full document, including every cluster and unplaced line.
ankra cost savings
Read the organisation’s savings model - the same recommendations the portal shows under Cost. The model analyses the biggest priced clusters (up to the organisation’s analysed-cluster limit, see ‘ankra cost settings’, and within the platform’s analysis time budget) and proposes the levers that apply to each: right-size idle capacity, reduce run rate no namespace claims, or an off-hours schedule (weeknights and weekends) for a known non-production cluster with no enabled power schedule. A cluster can carry several. The total counts each cluster once, at its best lever, so it is smaller than the sum of the rows when a cluster has more than one. Each row’s Basis says what its saving rests on: measured (observed usage planned a right-size step), billed (an off-hours stop on billed compute) or estimate (capacity less requests, with no usage measured). The total counts only measured and billed levers; what the estimates add is shown beside it and never counted. Clusters the model could not analyse are listed rather than treated as having nothing to save: unpriced (never had a cost snapshot), stale (metering stopped over a day ago), unreadable on this pass, and offline (the agent has not checked in, so nothing is recommended for them). The waste summary counts the open cloud-waste findings. Every figure is a list-price estimate in the organisation’s display currency.ankra cost settings
Pricing settings: display currency, effective discount, the network egress estimate and the analysed-cluster limitankra cost settings get
Show the organisation’s pricing settingsankra cost settings set
Change one or more pricing settings. Only the flags you pass change; the other settings keep their current values. The route is organisation-admin only and every fleet and cluster figure re-prices on the next read.--analysed-cluster-limit sets how many of the costliest priced clusters the
savings model analyses (1 to 50); --analysed-cluster-limit default returns it
to the platform default of 8. Without the flag the limit is not sent, so it
keeps its stored value.
ankra cost summary
Fleet cost rollup: projected month end, month to date, run rate, by provider and costliest clustersankra cost trend
Read the organisation’s cloud cost run rate per UTC day over every priced cluster - the line the portal draws under Cost. A cost snapshot exists only for an hour a cluster was priced, so a cluster missing from a day was not priced that day: it did not cost nothing. Each day says how many clusters it covers, and a day with no priced cluster is “not priced”, never zero. A day where some priced clusters were only partly priced (a node or billed resource with no price) is a floor. When the set of priced clusters changes - a cluster is created, deleted, stopped or loses its pricing - the line moves without anything being spent. Those days are listed apart, with the clusters that entered and left and what that moved the line by: a coverage move, not a spend move. The last day is the current run rate, the same figure ‘ankra cost summary’ shows.--days sets the window (the platform keeps 35 days of snapshots and serves at
most 34; 30 when omitted). Pass -o json (or yaml) for the full document.