Cloud Server Overselling: Evidence Collection and Ticket Writing Guide

3 steps to secure overselling evidence; here's how to write tickets that work

Updated 2026-09-05 · CloudWorth

oversellingevidence collectionsupport ticketperformance testingCloudWorthSteal TimeVPS oversellingVPS benchmark

Secure evidence with system-level logs + timestamps + third-party notarization, and point tickets directly at SLA breaches.

How to Test Overselling

Don’t rush to judge a provider with benchmark software. If they fire back “your testing method isn’t rigorous,” all your pretty screenshots are useless. Overselling is essentially overallocation of physical resources, but the symptoms hide in two subtle places: CPU Steal Time and the disk Cache cliff.

First run a baseline during a low-load period: use top -d 5 to record steal values for 10 minutes. A normal cloud server should be below 1%; if it stays above 5%, neighboring VMs are pinching your vCPU. For disk I/O, don’t just watch the peak numbers in fio — look at the throughput curve while writing 10 GB continuously. Once the cache on an oversold host is exhausted, IOPS collapse like a cliff, and that’s not something “test methodology” can change.

Run the same test at three different times (e.g., off-peak, evening peak, early morning) and keep the raw output for each run. If you’re not familiar with Steal Time, follow the checklist we’ve prepared, or check the automatic diagnostic examples in /app. Remember: you’re testing whether your resources are being stolen by neighbors, not whether it feels “slow.”

How to Solidify Evidence

The goal of evidence collection is not to prove that "performance is poor," but to prove that "resource commitments do not match the SLA." Therefore, each piece of evidence must carry four elements: timestamp, command or tool name, raw output, and runtime environment.

Combine date -u +%FT%TZ with the test command so the logs carry UTC time; then use script -a session.log to record the entire terminal session, avoiding any suspicion of retroactive fabrication. For screenshots, keep the title bar and system time visible. It is recommended to record the screen with a phone and read the current time aloud at the beginning of the recording—this is the most primitive third-party time anchor. For screenshots of the abrupt drop in disk cache, pair them with continuous iostat -dx 5 logging saved as CSV, which is more persuasive than a single image.

Don't forget "cross-validation": the two test rounds should be spaced more than 6 hours apart, ideally spanning a "renewal cycle" or "neighbor tenant business peak." If you only test once, the other party can deny it; but if you obtain repeated results on different dates and under different loads, the evidence chain is closed.

Smarter people will also extract a cost-performance curve from the same evidence: at the same price point, is your allocatable CPU share 30% lower than the public cloud baseline? Although this does not directly prove oversubscription, it can elevate a "technical dispute" into a "FinOps premium loss," turning the ticket from "you lied" into "I lost money."

How to Write a Support Ticket

The golden rule for tickets is: state only facts, not conclusions. Don't say "you're overselling"; say "observed CPU steal averaging 12%, disk cache dropped 4 times." Don't say "performance is unqualified"; say "based on the CPU performance commitment in your SLA, current performance deviates from the baseline."

Recommended structure:

1. Environment description: instance configuration, operating system, time range.
2. Testing method: attach reproduction commands (use generic commands, not BT Panel or third-party benchmarking tools).
3. Raw data: three sets of steal logs, disk CSV, timestamped screenshots, packaged as attachments.
4. Impact description: specify the concrete impact on business (e.g., API response rose from 80ms to 2s).
5. Request: ask the official side to recheck the host load status and provide resource allocation details.

A template can start like this:

"Our instance ran the same test three times on 2025-06-01 at 02:00, 08:00, and 20:00; samples are attached. CPU steal exceeded 8% each time, and after the disk cache hit bottom, IOPS fell to less than 20% of the rated value. Since your SLA commits to baseline CPU and I/O performance, please ask your technical team to verify the current allocation ratio and neighbor load on the physical host."

Note: Do not use words like "complaint," "overselling," or "fraud" in the body — save those for after customer service escalates the issue. The value of a ticket is that it prevents the other side from rebutting with "your tools are inaccurate," so every piece of data must correspond to a complete log line. If they reply "please use our testing tools," you can answer: "We have re-tested according to your documentation; see the third set of data in the attachment." In this way, you firmly throw the ball back to them.

What If the Provider Refuses to Acknowledge?

When they reply that "the test method is flawed" or "the host load is normal," don't rush to argue. First, ask them to provide host monitoring logs for the same period — they often cannot produce them or can only offer a stripped-down version. At this point, you already have two sets of hard evidence: line-by-line logs showing CPU steal exceeding 8%, and a curve of IOPS dropping to 20% of rated performance after the disk cache bottomed out. Turn these two datasets into a time-aligned comparison table and point out: if the disk cache cliff coincides exactly with the steal peak, it indicates that the host's CPU and storage resources were simultaneously squeezed by neighbors — this is not single-test jitter, but a typical form of resource pool oversubscription.

If they still insist that the "tool is inaccurate," you can reply: "Please provide your company's officially recommended test scripts and parameters. I will re-run the tests according to your documentation, with a third-party notary recording the process." The value of this step is to shift the burden of proof back to the provider. At the same time, conduct two more independent tests on different dates (e.g., early morning and evening peak), forming cross-validation. If all three samples point to the same conclusion, they cannot fob you off with "coincidence." Be sure to keep raw logs from each test, system time, NTP sync records, and timestamps from screenshots — these are materials for later escalation to higher-level channels.

Escalating Complaints and Refunds

If the direct customer service department refuses to escalate, initiate channel escalation: first, send an email to the abuse/complaint address published on the provider's official website, with the subject line stating “SLA breach evidence attachment number”; second, submit materials to the communications administration bureau in the cloud provider's jurisdiction or the 12321 Network Bad and Spam Information Reporting Center. When submitting, do not repeat test conclusions—just list the facts: which day, which instance, what tests were run, what the result values were, and which SLA clause they correspond to.

Refund requests should be handled in two steps. First, apply for a “refund for unused time” according to the provider's refund rules, and state that business losses were caused by substandard resources, demanding additional compensation—at this point you can do the math from a FinOps perspective: you paid a premium for a nominal 8-core 16G, but the actual available computing power is only equivalent to 3 cores, so the cost-effectiveness is already out of balance. If the other party is only willing to refund part of the fee, insist that they issue a “resource allocation statement” and specify whether the instance shares a host machine with high-density cheap VPS instances. Most providers will offer a compromise plan because they are afraid you will use this statement to report overselling.

Final reminder: conduct all communication through tickets or email, and keep screenshots. If you apply for a refund, remember to export the disk data first before deleting the machine—after the refund, the instance will be wiped, and your forensic logs need to be kept for at least 180 days for future arbitration or litigation. Even if the refund is successful, it is recommended to apply this forensic method to the next provider, verify thoroughly before paying, to avoid falling into the same trap again.