# What is a noisy neighbor?

A noisy neighbor is another tenant on shared hardware whose heavy use of CPU, memory, disk or network slows your workload down.

**On Runtime every sandbox has a guaranteed CPU floor, its own memory, a fair
share of the disk and network limits, all enforced on the host outside the
guest.** Its disk gets at least about 40 MB/s however busy its neighbours
are, and up to about 1 GB/s when they are not, so one busy sandbox cannot
starve the others on its server
([the sandbox environment](/docs/sandbox-environment#disk-cpu-and-memory)).

## Where the term comes from

Microsoft's Azure Architecture Center describes it as an antipattern of
multitenant systems: the problem "occurs when one tenant's performance is
degraded because of the activities of another tenant". It can happen when one
tenant uses a disproportionate share, or when many small tenants peak at once.
From the outside it looks like a request that succeeds most of the time and
fails, or slows, at random.

## What a neighbor can take from you

| Shared resource      | What goes wrong                         | How a platform limits it                     |
| -------------------- | --------------------------------------- | -------------------------------------------- |
| CPU time             | Your threads wait for a core            | A guaranteed share per tenant, capped bursts |
| A core's two threads | Cache and execution units are contested | Core scheduling keeps strangers off one core |
| Memory               | The host swaps or kills processes       | Fixed memory per tenant                      |
| Disk I/O             | Latency spikes behind someone's writes  | A rate limit with a burst allowance          |
| Network              | Throughput drops                        | Per-tenant bandwidth caps                    |

The Linux kernel's documentation describes core scheduling as letting
userspace "define groups of tasks that can share a core", so that "only trusted
tasks" run side by side on the two threads of one core.

## The Runtime answer, in numbers

- **CPU:** a floor of a twentieth of a vCPU by default, raised with
  `cpuFloorMillis`, or every vCPU reserved with `cpu: "reserved"`
  ([shared vs reserved CPU](/glossary/shared-vs-reserved-cpu)).
- **Memory:** what the sandbox asks for, up to 64 GiB on a paid one.
- **Disk:** the host's kernel divides the drives between busy sandboxes in
  proportion and holds every read and write near a latency target, so a
  heavy writer next door slows your writes a little and never stops them.
- **Network:** a paid sandbox moves up to 500 GiB a day
  ([pricing](/docs/pricing#network-products)).

## Related

- [What is a CPU floor?](/glossary/cpu-floor)
- [What is CPU overcommitment?](/glossary/cpu-overcommitment)
- [What are cgroups?](/glossary/cgroups)
- [What is a vCPU?](/glossary/vcpu)

## Sources

Checked 27 September 2026.

- [Noisy Neighbor antipattern, Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor)
- [Core scheduling, the Linux kernel documentation](https://docs.kernel.org/admin-guide/hw-vuln/core-scheduling.html)