Purpose & Scope
Game servers on a shared node share the same physical CPU. Most of the time that works well, because servers rarely all need everything at once. This Policy exists so that the few moments when they do are handled in a way that is predictable, proportionate and transparent, rather than at our discretion.
This Policy applies to every game server and container hosted on Scooperdive infrastructure. It is incorporated into our Terms & Conditions alongside our other policies.
How this Policy fits with our other documents:
- CPU limit on your plan: The size of your CPU limit is set by the plan and configuration you selected at checkout (or in a written agreement with us). This Policy does not change it, other than the temporary step described in Section 6.
- Automated CPU management: For the automated management of CPU on shared servers, this Policy is the rule. If it differs from the general wording in our Acceptable Use Policy, this Policy applies.
- Abuse is separate: Fair use is a no-fault, automatic process. It is not a penalty, and it is separate from enforcement of our Acceptable Use Policy and Terms (for example for crypto-mining, deliberate crash loops or attacks), which are not limited by this Policy. See Section 7.
- Uptime: Availability commitments and credits are governed by our Service Level Agreement.
Shared & Dedicated CPU
Every server runs in one of two CPU modes:
| Mode | What it means | Fair use limiting |
|---|---|---|
| Dedicated cores | Staff assign specific CPU cores to the server. Only that server runs on them. | Does not apply. |
| Shared | No dedicated cores. The server runs on the node’s shared pool of cores together with other shared servers. | Applies, as set out in Sections 4–8. |
Unless your plan or a written agreement states that it includes dedicated cores, your server is a shared server.
Dedicated Cores
What a dedicated core is
A node has a number of CPU threads. Staff can assign some of them to one server by number (for example “cores 2 and 3”).
- Exclusive: Assigned cores belong to that one server on that node. They cannot be assigned to any other server, and our systems enforce that.
- Kept clear: Servers without dedicated cores are restricted to the remaining cores, so a dedicated core is free of other customers’ workloads.
- Shared pool is protected: Every node keeps at least one thread for shared servers and system processes, so not every thread on a node can be dedicated.
- Plan CPU limit still applies: A server with 2 dedicated cores and a 150% CPU limit uses at most 1.5 cores’ worth of CPU. Dedicated cores guarantee who shares your cores (nobody), not that your limit is larger.
Who can change it
Only Scooperdive staff can assign, move or release dedicated cores. Customers cannot do so themselves. Staff changes are recorded in the server’s activity log.
When your plan or service changes
Dedicated cores are provided only where your plan or a written agreement says so. If your service is cancelled, suspended for non-payment, terminated, or moved to a plan that does not include dedicated cores, the cores are released back to the node’s pool and the server becomes a shared server.
Nothing about dedicated cores is exempt from our Acceptable Use Policy.
What We Measure
Once a minute our control panel asks each node how much CPU every running shared server is using. The figure is the server’s container CPU as a percentage of one thread (so 200% means two full threads). From this we calculate two things:
- The server’s average CPU over a rolling window of 30 minutes.
- The pool’s load: the combined CPU of all running shared servers on the node, divided by the number of shared cores, averaged over the last 10 minutes. Dedicated-core servers are not part of this figure, nor is CPU used by the node’s own system processes.
When Fair Use Applies
Fair use acts only when both of the following are true at the same time:
- The server is “heavy”: its average CPU over the last 30 minutes is at least 90% of its own CPU limit (a server with no CPU limit is compared with one full thread), and we hold at least 80% of that window’s measurements. A short spike never counts, and a freshly started server needs roughly 24 minutes before it can be called heavy.
- The node is “busy”: the shared pool has averaged at least 85% over the last 10 minutes (with at least 5 minutes of data).
The Steps
If, and only if, a server is heavy while its node is busy, the following steps apply in order:
- Notice. The server is marked with a notice. The event is written to the server’s activity log and a short message appears on the server’s page: heavy use while the machine is busy, nothing has changed, and the CPU limit may be lowered if it continues. Nothing else happens at this step.
- Wait. We wait at least 30 minutes after the notice. If the server is no longer heavy or the node is no longer busy, the notice is cleared and nothing happens.
- Lower the CPU limit. If the server is still heavy and the node is still busy, its CPU limit is lowered to 75% of its plan limit for at most 60 minutes. The change is applied live: your server keeps running and is not restarted.
- The limit is never lowered below 50% of your plan, and never below half a thread (50%).
- A plan with a CPU limit of 50% or less is left as it is.
- A server with no CPU limit is given a limit of 75% of its recent average, but never less than one full thread.
- Restore. The original limit comes back automatically after 60 minutes, or earlier (after at least 10 minutes) once the pool’s load drops below 60%.
- Cooldown. For 6 hours after a limit ends, the server is not given a notice or limited again.
Your plan, its stated limits and your billing record are never changed. The lowered limit is a temporary override that applies only while it lasts.
What Fair Use Never Does
The automated fair use process described in this Policy will never:
- Stop, restart, suspend or delete a server.
- Limit memory, disk, network, backups, databases or players.
- Act on a server with dedicated cores.
- Act on a server that staff have exempted.
- Lower a limit by more than 25% of your plan, or for more than one hour at a time (with default settings, and always within the hard limits in Section 8).
Settings & Hard Limits
Staff can adjust the numbers used in this Policy, but only inside fixed bounds built into our systems, so the policy cannot be made harsher by accident. Fair use can also be switched off entirely.
| Setting | Default | Never outside |
|---|---|---|
| Node counts as busy at (pool average) | 85% | 70–100% |
| Server counts as heavy at (share of its own limit) | 90% | 80–100% |
| Heavy for at least | 30 minutes | 15–120 minutes |
| Time between notice and any limit | 30 minutes | 15–240 minutes |
| Lowered limit (share of your plan) | 75% | 50–95% |
| A limit lasts at most | 60 minutes | 15–240 minutes |
| Cooldown afterwards | 6 hours | 1–24 hours |
The defaults above are what apply unless this page says otherwise. The “never outside” column is a commitment: we will not go beyond it without amending this Policy under Section 13. A tighter setting that still sits inside these bounds will always continue to include a notice first (Section 6, step 1).
Notice, Records & Your Data
How you are told
- A banner on your server’s page, in plain words, during a notice or a limit. During a limit it also says when the limit should end and that dedicated cores avoid this.
- Entries in the server’s activity log.
- We do not currently send an email for fair use notices. Check the server page and activity log, and make sure anyone who manages a server for you knows to look there.
What is recorded
For each flagged server we store the current step, the lowered limit, the server’s average CPU at the time, and the times of the notice, the start and end of any limit, and the cooldown. The activity log records the notice, the limit (with the lowered figure), the restoration and the clearing, each with the server’s average CPU and the pool’s load. Any staff action on fair use (exempting a server, lifting a limit, changing the policy settings) is logged against the staff member.
Personal data
CPU measurements are tied to a server and therefore to an account, so we treat them as personal data. The minute-by-minute figures are held in the control panel’s memory only, for no longer than the measurement window (up to 30 minutes); they are not written to our database and are lost when the panel restarts. Only the outcomes and activity log entries described above are stored, and they are kept in line with the retention schedules in our Privacy Policy. Our lawful bases are performance of our contract with you and our legitimate interest in keeping the shared platform fair and stable for all customers.
Performance Expectations
We would rather be upfront about the limits of what any shared platform can promise:
- A CPU limit is a ceiling, not a guaranteed speed. Shared servers share cores. Even with no limiting at all, a busy node can make a shared server run slower than its limit would otherwise allow. If you need CPU that is not shared with other customers, that is what dedicated cores are for.
- Measurements are averages taken once a minute. Very short bursts are not seen, and decisions use 10- and 30-minute averages.
- Restarts reset the measurement windows. After a control panel restart, no server can be called heavy for about 24 minutes.
- An unreachable node cannot be measured or changed. If we cannot reach a node, nothing is measured or changed there. A limit already applied may stay in place past its end time until the node next refreshes its settings (for example when the server restarts or staff change it). If this affects you, contact support and staff can lift it.
- Dedicating cores shrinks the shared pool. We aim to keep enough shared cores on each node for the shared servers on it.
Degraded performance as such is not “downtime” under our Service Level Agreement. Nothing in this Policy limits any rights you have by law, including the right to have services provided with reasonable care and skill.
Moving Between Nodes
If we move a server to another node (including at your request), the following applies to dedicated cores:
- By default the server is given the same core numbers on the new node if they are free there. If not, it is given the lowest free cores. Staff can instead choose specific cores. The number of cores always matches what the server has now.
- The new cores are reserved the moment the move starts, so nothing else can take them while the files copy.
- The old node’s cores are released only after the new node confirms the move worked. If a move fails or is cancelled, the server keeps its old cores.
- A move is refused if the new node does not have enough free cores.
Because the core numbers, and sometimes the server’s address, can change on a move, tell us before the move if you rely on a particular address or configuration.
Review, Exemptions & Contact
Fair use is automatic, which means it can occasionally get a case wrong. If you think it has, you can ask us to look at it:
- Open a ticket in our Support Center or ask in our Discord, with your server name and the time of the notice.
- Staff can lift a limit immediately.
- Staff can exempt a server from fair use (for example under a written agreement with us), which also ends any current limit.
- Where heavy use is legitimate and sustained, we would rather talk to you about moving to dedicated cores or a larger plan than keep limiting a shared server.
For formal queries about this Policy, write to [email protected].
Changes to this Policy
We may update this Policy, for example as our infrastructure changes. Changes are made under the amendment terms of our Terms & Conditions, and the “Last Updated” date and version at the top of this page will change when they are.
Changes to the numbers in Section 8 that stay inside the “never outside” bounds are operational adjustments and will be reflected in the defaults shown on this page. We will not make fair use harsher than those bounds, or remove the notice step, without amending this Policy.