# Idle Neptune Cluster -- No Requests

> Neptune clusters publish request metrics only when values are non-zero, so ZopNight anchors idle detection on 30 days of CPUUtilization below 5% and treats absent Gremlin, SPARQL and openCypher series as confirmation. A cluster quiet on every axis is flagged for its full single-instance compute run-rate.

Source: https://zop.dev/integrations/aws/recommendations/idle-neptune-cluster-no-requests
Updated: 2026-08-19

---

## Absence of request metrics is the signal, not a gap

Neptune has an unusual CloudWatch behaviour that shapes this whole rule: [among the series it publishes](https://docs.aws.amazon.com/neptune/latest/userguide/cloudwatch.html) it sends
`GremlinRequestsPerSec`, `SparqlRequestsPerSec` and `OpenCypherRequestsPerSec` only when the
value is non-zero. A genuinely idle cluster therefore has few or zero datapoints on those
series across the entire window, and that empty series *is* the evidence of no queries.

An earlier revision of this rule missed that, requiring each request axis to carry 30 days of
its own datapoints. A non-zero-only metric can never accumulate coverage on an idle cluster, so
the rule abstained on exactly the clusters it existed to find. The current logic treats an
absent request series as idle-consistent, and vetoes the finding the moment any present series
shows an average or peak at or above 0.10 requests per second.

## CPU anchors the 30-day evidence window

Since silence on the query axes proves nothing about whether telemetry is even flowing, the
evidence window rides on `CPUUtilization` instead, a series a running Neptune instance reports
continuously. The rule requires it to be present, covered for at least 30 days, and under 5% on
both average and peak. A cluster answering no queries but burning CPU on replication or a
scheduled bulk load is doing real work, and deleting it would be wrong; missing or
under-covered CPU means the window itself cannot be trusted. Either way: abstain.

## The openCypher axis is declared but not yet harvested

The openCypher floor of 0.10 requests per second is wired into the rule, but the metrics
pipeline does not collect that series yet. Today the axis is always absent, which reads as
idle-consistent, so an openCypher-only cluster with heavy traffic is protected only by the 5%
CPU veto until the collector lands. Once it does, the same gate becomes a real per-language
veto with no rule change.

## Query the Gremlin request rate yourself

```bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/Neptune --metric-name GremlinRequestsPerSec \
  --dimensions Name=DBClusterIdentifier,Value=my-graph-cluster \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum
```

An empty result is expected for an idle cluster, given the non-zero-only publishing. Check
`SparqlRequestsPerSec` and `CPUUtilization` the same way.

## What the Neptune saving covers

The dollar figure is the cluster's single-instance compute run-rate: it excludes [the standing
storage and I/O lines Neptune bills alongside compute](https://aws.amazon.com/neptune/pricing/) and is not multiplied by instance count. Deleting recovers all of it. With no priced
cost the rule reports nothing. Snapshot the cluster before removal, and weigh Neptune
Serverless if the workload is intermittent rather than gone.