What to Do When 2026 Burstable Cloud VM CPU Credits Run Out?

A CPU credit represents one vCPU running at 100% utilization for one minute in the documented credit model. That makes credit balance a measure of accumulated burst capacity, not a direct measure of application health. The official credit-model documentation explains the unit and baseline concept.

Suitable for a diagnosis: first confirm that the VM uses CPU credits, then match the credit balance and CPU usage to business symptoms.
Not suitable for an immediate migration decision: credit depletion alone does not prove that a dedicated server will be cheaper or solve the actual bottleneck.

This guide is for:
- Cloud operators checking whether credit depletion coincides with slower requests.
- Infrastructure budget owners comparing the current VM, a resized instance, and a dedicated option.
- Application and database teams deciding whether continuous CPU demand fits a burstable VM.

Last updated November 2, 2026. Model behavior and metric references were checked against the official documentation linked below. Recheck the documentation before changing a production instance.

Confirm the credit model and its depletion behavior

A burstable VM earns credits while it runs below a defined baseline and spends them when CPU use exceeds that baseline. The balance can therefore fall even when CPU usage looks ordinary for a short period: the relevant question is whether demand is persistently above the baseline, not whether a single CPU graph has a high point.

The outcome at depletion is platform- and mode-specific. In the documented B-series model, credit balance and baseline performance determine how much bursting capacity is available. The B-series CPU credit model describes the model for that series; it is not a rule for every cloud VM. Other documented burstable-instance modes distinguish standard behavior from modes that permit surplus usage. The standard-mode rules and surplus-credit examples explain why depletion must not be confused with an automatic extra charge: charges depend on the specific model and mode.

Before interpreting a slowdown, record the exact instance family, size, operating mode, and the provider’s stated behavior when credits are low or exhausted. Do not infer that behavior from a different VM family or another provider’s documentation.

Check the metrics against the workload

Find the platform’s credit balance and consumption metrics, then compare them with CPU utilization and user-facing symptoms. Depending on the platform, a dashboard may label a balance with a name such as “CPU Credit Remaining,” while another exposes separate balance and usage metrics. Confirm the actual metric names and definitions in the provider’s documentation: the CloudWatch credit metric guide and the virtual machine metric reference describe platform-specific monitoring.

Use the same time window for every column. A balance reading from one period cannot reliably explain a latency spike from another. Include application response time, queue depth, database activity, and any workload change that could explain the timing.

A low balance is evidence of reduced burst headroom. It is not proof by itself that the application is CPU-bound. The useful signal is alignment: credit depletion and sustained CPU demand should occur during the same period as a relevant service symptom.

Separate CPU credit limits from other bottlenecks

A VM can show poor response times for reasons that a CPU credit adjustment will not fix. Compare the following observations before changing the instance:

Do not confuse CPU credits with CPU steal. Credits describe a burst-capacity model exposed by a provider; steal time is a guest operating-system measure of time a VM waits for CPU scheduling. A credit balance cannot establish whether a host is oversubscribed, and a high steal reading does not establish that credits are depleted.

The same distinction applies to memory and storage. If the database is waiting on disk or the operating system is swapping under memory pressure, moving to a higher CPU baseline may leave the main cause untouched. Review application logs alongside operating-system monitoring and the platform dashboard. The official high-CPU troubleshooting guidance recommends correlating CPU activity with processes and workload changes rather than treating one graph as a complete diagnosis.

Choose the next capacity option

Use the workload pattern—not the credit balance alone—to choose a response. A short spike from a scheduled import calls for a different decision from an API or database that stays CPU-bound throughout ordinary business traffic.

Use actual invoices and the provider’s official pricing page for the same region and billing period. Include the VM, disks, public addresses, data transfer, backups, and any attached services that would remain after a change. For a dedicated option, use the current product table rather than assuming that a cloud VM’s vCPU count maps directly to a physical server’s capacity. XFP Cloud’s billing information can be checked alongside the current cloud invoice when building that comparison.

Apply a decision branch before changing production

Use these conditions to narrow the choice:

• If the instance does not use a credit model, then investigate the actual VM limits and workload bottleneck instead of treating the balance as a cause.
• If credits fall, CPU stays busy, and latency or queues worsen in the same periods, then compare a larger burstable VM with a fixed-performance VM.
• If high CPU demand is brief and tied to a controllable task, then test scheduling or workload tuning before committing to a larger baseline.
• If demand is steady, resource requirements are known, and the team can manage the operating system and recovery process, then include dedicated-server rental in the comparison.
• If the application depends on rapid scaling, multiple regions, or deeply integrated managed services, then keep those components in the cloud unless a tested replacement meets the same needs.

The comparison should use the same workload assumptions. A cloud VM that scales automatically and a fixed server that requires manual capacity planning do not have the same operating model, even if their monthly compute charges look close.

Verify the alternative with a reversible test

Before expanding a change, define what a successful test would mean for the application. Choose indicators the team already monitors: request latency, error rate, queue growth, database response, CPU saturation, and recovery behavior after a job. Record the current values over representative periods so a candidate option can be compared against the same workload.

Use a test environment or a reversible production change where possible. Keep the existing VM configuration documented, preserve a tested rollback path, and avoid changing the application, instance size, and storage layout at the same time. Otherwise, a result may not reveal which change caused the improvement or regression.

Before migration, verify dependencies and operating responsibilities:

• Check required CPU capacity, memory headroom, disk space, and network throughput against measured demand.
• Confirm how data will be copied, validated, backed up, and restored if the migration fails.
• Identify managed databases, queues, scheduled services, and other cloud features that would need replacements.
• Assign responsibility for operating-system updates, monitoring, incident response, and hardware recovery.
• Confirm the team can restore the service from its own backup plan; dedicated resources do not automatically provide high availability, backup, or managed operations.

For a potential XFP Cloud deployment, compare the measured resource baseline with the configurations and prices in the current product table. Do not assume that CPU credits, cloud scaling behavior, or a VM’s reported vCPU count describe the capacity of a physical server. The server configuration guide is a place to review the available options; use the site’s current product information for actual capacity and cost.

Quick answers

Can a low balance alone confirm that credit depletion caused the slowdown?
No. Match the balance and usage metrics to CPU utilization and application symptoms in the same periods. If the balance falls without sustained CPU demand or user-visible effects, keep investigating rather than resizing immediately.

Can credit exhaustion create extra charges?
Not as a universal rule. Some credit models describe performance behavior at depletion; particular modes may permit surplus usage under separate charging rules. Check the official documentation for the exact VM family and mode, and confirm any charge on the provider’s invoice.

What if CPU usage is high but the balance is not falling?
Check whether the VM actually uses credits and whether the dashboard metric belongs to its instance family. Then investigate other limits, CPU scheduling, memory pressure, storage latency, and application-level contention. A metric from another family may not apply.

How should a team compare a fixed-performance VM with a dedicated server?
Use the same workload, region, and billing period, then compare the full invoice and operating responsibilities—not compute charges alone. Include storage, network, backups, scaling needs, recovery procedures, and staff time. Keep cloud services that provide essential elasticity or managed functions unless their replacements have been tested.

Match the solution to the workload

A burstable cloud VM remains a reasonable choice when CPU demand is mostly modest, spikes are occasional, and cloud elasticity or managed services matter more than fixed resource ownership. If credit depletion repeatedly coincides with sustained CPU demand and service degradation, compare a resized instance and a fixed-performance option before deciding that migration is necessary.

When the workload is stable, resource requirements are measured, and the team is prepared to own backup and recovery procedures, XFP Cloud’s dedicated AMD server option is worth evaluating against the current cloud arrangement. That comparison should account for the cloud VM’s variable capacity rules and attached charges, while also recognizing that a dedicated server does not provide automatic scaling, high availability, or managed backups. Use the measured baseline and current product table to decide whether the change fits; do not treat a different hosting model as a guaranteed performance or savings result.

Questions

1. What happens when a burstable cloud VM runs out of CPU credits?

   It depends on the provider, instance family, and credit mode. Some documented models reduce CPU performance toward the instance baseline when credits are depleted; other modes can allow surplus usage and apply charges under their own rules. Check the official documentation for the exact VM and mode, then confirm the behavior against your metrics and application response times.

2. How can I check CPU credit balance and how quickly it is falling?

   Use the cloud platform’s monitoring service to find its credit balance and credit usage metrics for the exact VM family. Compare those readings over the same time windows as CPU utilization, request latency, queue depth, and database activity. Metric names and availability vary, so verify them in the platform’s official monitoring reference rather than assuming a label is universal.

3. Should I change instance size if CPU credits keep falling?

   Not automatically. First establish whether sustained CPU demand is above the instance’s baseline and whether that demand coincides with user-visible latency or growing queues. If it does, compare a larger burstable size with a fixed-performance option using the same billing period and regional pricing. If the drop matches a temporary job, scheduling or tuning that job may be enough.

4. Is a burstable VM suitable for a website or database that runs continuously?

   It can be suitable when average CPU demand stays within the instance’s baseline and higher demand is occasional. A workload that remains CPU-bound for long periods may repeatedly exhaust credits and behave unpredictably under its current plan. Measure representative traffic and database activity first; then compare a fixed-performance VM or dedicated server, including the operational work your team must take on.