---
title: Ratecounter
summary: null
url: https://www.fastly.com/documentation/reference/vcl/declarations/ratecounter
---


> **NOTE:** The [Edge Rate
    Limiting](/guides/security/rate-limiting/working-with-rate-limiting-policies)
    product must be enabled on your account by a Fastly employee in
    order to use the primitives described on this page.

A `ratecounter` stores entries that count increments against keys and
uses these to estimate the rate at which each key is being
incremented. Increments are collected into keyed buckets that
represent overlapping and progressively longer periods of time. The
`ratecounter.{NAME}.bucket.60s` reflects all increments in a 60s
window that includes the current time, while
`ratecounter.{NAME}.bucket.10s` only counts those that have occurred
in the 10 second window that includes the current time. When an entry
has received zero increments for the just-completed minute, and
therefore all its buckets have a value of zero, they are deleted from
the ratecounter.

Time windows are fixed and almost always incomplete. For example, if
the current time is 12:01:03.458, then `ratecounter.{NAME}.bucket.10s`
represents increments received between 12:00:54.000 and
12:01:03.458. That window will continue until the current time is
12:01:04.000, at which time the window starting time will change to
12:00:55.000. When the current time rolls over to a new whole second,
the window starting time will advance by one second to ensure that the
window size continues to represent the most recent 10 seconds.

The result of this behavior is that the `10s` window contains a
minimum of 9 seconds, and a maximum of 10 seconds, of increments. The
same logic applies to the other window sizes.

Rate counters are a primitive that is used primarily in constructing
[rate limiting](/guides/concepts/rate-limiting) solutions.

Each ratecounter can contain up to 200,000 entries per
[site](/guides/concepts/pop) and, once that limit is reached, each new
entry will evict the least recently incremented entry.

All the [cache nodes](/reference/glossary#term-cache-server) within
the [site](/guides/concepts/pop) communicate with each other, sharing
information about the counts in order to converge on a single
value. Because of synchronization delays, the first time a ratecounter
is used on a given cache node it will appear to have zero counts
because it is not yet synchronized with the rest of the cache nodes in
the site. Once synchronization is complete, the ratecounter will
converge to an accurate value across the site.

Rate counters do not have any properties and should be declared as an
empty block:

```vcl
ratecounter requests_rate {
  # no properties
}
```

## Operations

The following functions operate on `ratecounter` instances:

* `ratelimit.check_rate`
* `ratelimit.check_rates`
* `ratelimit.ratecounter_increment`

The following variables provide current counts for `ratecounter`
instances:

* `ratecounter.{NAME}.bucket.10s`
* `ratecounter.{NAME}.bucket.20s`
* `ratecounter.{NAME}.bucket.30s`
* `ratecounter.{NAME}.bucket.40s`
* `ratecounter.{NAME}.bucket.50s`
* `ratecounter.{NAME}.bucket.60s`