Verification Guide

0What this is

The supported method for verifying, from inside your own virtual machine, that you are getting the resources you pay for. Results produced this way are what the SLA commits to honoring (SLA 4.1). Everything runs with standard Linux tools. There is nothing to install from us, no agent, and nothing phones home.

1Who can run this

Any plan with shell access (co-managed and full control). Fully managed plans have no shell; email office@gummies.cloud and we run the checks with you and send you the raw output.

Requirements: procps (provides vmstat; present on our images by default) and sysbench for check 3 (apt install sysbench).

2Check 1 · CPU steal

What it shows: time your virtual CPU was ready to run but the host ran something else instead. On a dedicated core this should be effectively zero at all times. Steal is caused by the host, never by your own load; a server maxing its own CPU shows 100% us/sy and 0%st.

One full SLA Measurement Window (60 minutes at 10-second samples):

vmstat -t 10 360 | tee steal-$(date +%F-%H%M).log

Quick five-minute spot check:

vmstat -t 10 30

Read the st column (the 17th). Discard the first data row; it reports averages since boot, not the current interval.

Average a recorded window:

awk '$1 ~ /^[0-9]+$/ { if (seen++) { sum += $17; n++ } } END { printf "samples=%d  avg st=%.3f%%
", n, sum / n }' steal-*.log

SLA trigger (section 3): average above [1%] across one full Measurement Window on a Dedicated vCPU.

3Check 2 · reserved RAM

What it shows: your memory is present, full-size, and stays that way.

grep -E 'MemTotal|MemAvailable|SwapTotal' /proc/meminfo

MemTotal should match the published expected value for your plan[table published at launch] and should never change while the machine runs. It sits slightly below the raw plan size because the kernel reserves some memory at boot; the reservation is a constant per plan, not a moving number.

Log it over time:

while true; do date; grep -E 'MemTotal|MemAvailable' /proc/meminfo; sleep 60; done \ | tee ram-$(date +%F).log

Honest limits of the guest view: host-level swapping of guest memory is not directly visible from inside a virtual machine. That is why SLA measurement is two-sided (SLA 4.3) and why the fleet transparency page publishes sold-versus-installed figures per node. On our design neither ballooning nor host swap should ever occur (SLA 2.1).

4Check 3 · CPU performance

What it shows: your cores perform like the reference hardware, not like an oversubscribed slice.

Run with your own workload stopped or idle; your own load skews the result.

sysbench cpu --cpu-max-prime=20000 --threads=<your plan's vCPU count> --time=60 run

Run it three times and take the median "events per second". Compare against the published reference range for your plan [published at launch]. Expected run-to-run variance is about[3%].

5Recording evidence for a claim

• Capture unedited terminal output: tee as shown above, or record the whole session with script -q claim-$(date +%F).log.
• Keep timestamps intact; vmstat -t and the datelines provide them.
• Include your Service identifier and the window you are claiming.
• Email it to office@gummies.cloud with the subject line "SLA claim" (SLA section 6).

6What we log on our side

For every virtual machine, sampled at [10 seconds] or less and retained at least [90] days: per-vCPU scheduling data (run, wait, and steal as the host accounts them), memory reservation state including any balloon or host-swap activity, and node-level sold-versus-installed totals (the same data the transparency page publishes). A valid claim appears in both your capture and this telemetry (SLA 3c).

7Reading the numbers

• st at 0 on nearly every sample on a dedicated core is what we expect, always.
• A single-sample blip at boot, or during an announced maintenance window while we move virtual machines between hosts to patch without downtime, is normal. It is not sustained and is not a Qualifying Failure.
• us plus sy at 100 with st at 0 is your own workload using the CPU you paid for. It is not steal.
• A high load average with st at 0 is queueing inside your VM, from your own processes, not host contention.
• MemTotal sitting a small fixed amount below plan size is the kernel's boot reservation. The published table lists the exact expected value per plan.

8Versioning

Versioned and dated alongside the SLA. The method above is the committed method (SLA 4.1). Changes take effect per SLA section 8.