This checker vs. reading the manifest by eye

Skimming a Deployment or StatefulSet's YAML during review is the default first pass, and every team already does it. It reliably misses a container whose resources block has some fields set but not the one that matters, and a request that exceeds its own limit two lines away -- exactly what this free tool checks automatically.

What reading the manifest in review involves

Reviewing a pull request that touches a Deployment or StatefulSet usually means scrolling to the resources block, confirming it exists, and moving on -- especially once a change has already passed a glance at everything else (image tag, replica count, probes). A block with real numbers in it reads as "resourced" at a glance, whether or not every field Kubernetes actually cares about is present.

That works well for a resources block that is missing outright, or an obviously malformed value. It works less well for a block with some fields set -- nothing about a container with a memory request calls attention to the memory limit it is missing -- or for two values that need to be compared against each other rather than read on their own, such as a CPU request under requests and a CPU limit under limits, sitting in different blocks.

The two gaps a visual review is most likely to let through.
What matters	Reading the manifest by eye	This checker
Every container has a memory limit, not just a request.	A block with a request already in it reads as resourced; the specific missing field is easy to not notice.	Checks each of the four fields by name and reports exactly which is absent, per container.
No request exceeds its own limit for the same resource.	Requires comparing two numbers that live in different blocks, sometimes several lines or containers apart.	Parses both quantities and compares them directly, catching the exact case the API server rejects at apply time.
An init container's resources, not just the main containers'.	Init containers are easy to skim past -- they run once and are not the "real" workload being reviewed.	Checks init containers with the same four fields as regular containers.
A manifest with several workloads in one file.	Attention naturally concentrates on the first or largest workload in a multi-document file.	Analyzes every document independently and reports findings per workload.

Reviewing the manifest is not wrong -- it is how a team catches most problems, including ones this tool does not check at all (image tags, security context, probes). What it automates is the specific, mechanical comparison a visual pass is most likely to skip: is every field present, and does any request exceed its own limit.

Run the free resource-limits checker

The same worked example a visual review would pass

This is this tool's own bundled worked example -- the "Load worked example" button on the checker loads it verbatim:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: checkout-api
        resources:
          requests:
            memory: 512Mi
          limits:
            cpu: 500m
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cache
  namespace: data
spec:
  template:
    spec:
      containers:
      - name: cache
        resources:
          requests:
            cpu: 2
            memory: 4Gi
          limits:
            cpu: 1
            memory: 4Gi

Read start to finish, both containers look resourced: checkout-api has a memory request and a CPU limit set, and cache has requests and limits for both memory and CPU. Run this checker's own detection logic against it and it reports 2 workloads, 2 containers left unbounded or invalid, plus 3 more worth reviewing: checkout-api has no resources.limits.memory at all, despite having a memory request; and cache requests 2 CPUs while its own limit is 1 -- a value the API server rejects outright at kubectl apply, not a style note. Neither container's resources block is empty, so neither issue is the kind a quick "does this have limits set?" glance would catch.

Common questions

Isn't reading the manifest in review enough?

It catches anything visible on its own line -- a resources block missing entirely, an obviously wrong indent. It works less well for a container that has some requests or limits set (so the block looks present and reasonable) but is missing one specific field, or for two numbers that live a few lines apart in different blocks (a request under limits vs. a request under requests) that need to be compared against each other rather than read in isolation. Neither miss is a sign of a careless reviewer -- the YAML looks completely ordinary either way.

How easy is it really to miss a missing memory limit by eye?

In this tool's own bundled worked example, a Deployment's only container sets resources.requests.memory: 512Mi and resources.limits.cpu: 500m -- a resources block that is clearly not empty, with two real values in it. Nothing about reading it draws attention to the specific field that is absent: resources.limits.memory. A reviewer confirming 'yes, this has resource limits set' from a glance at the block is not wrong about what they saw; they are answering a coarser question than the one that matters.

Why is a request exceeding a limit easy to miss in review?

Because the two numbers being compared sit in different blocks -- requests.cpu and limits.cpu -- often several lines apart, sometimes in a different container's section entirely once a manifest has more than one workload. Each individual line reads as valid YAML with a valid quantity. The problem only exists in the relationship between the two values, and Kubernetes does not point it out until kubectl apply or helm upgrade fails admission validation -- after the review that would have caught it earlier has already passed.

Does this tool replace reviewing the manifest?

No, and it checks only resource requests and limits -- one narrow slice of everything a manifest review covers, such as image tags, security context, or probes. Reviewing the manifest is still how a team catches most problems and agrees the change makes sense. This tool exists for the specific, mechanical part of that review that benefits from being checked the same way every time: is every required field present, and does any request exceed its own limit.

See how this compares to a broader, deployed policy engine: this checker vs. Polaris. More on the mechanism behind each finding: why a missing resource limit takes down a node.