---
id: w3/m4.5/t004
title: "Prometheus retention bump + Render-like time-range presets"
worker: worker3
status: done
estimate: 30m
depends_on: [w3/m4.5/t001]
---

## Objective

Make the longer time ranges real: raise Prometheus retention (currently 3h, ephemeral) so bex's existing "Last 12 hours" — Render's default range — actually holds data, and add the intermediate presets Render offers.

## Context

- `deploy/gitops/base/prometheus.yaml`: `server.retention: 3h`, `persistentVolume.enabled: false` — a 12h query on prod today can only ever show the trailing 3h (and loses everything on pod restart). The metrics.go month-to-date bandwidth accuracy note names this same limit.
- Cardinality is tiny (two scrape jobs, one small cluster) — retention is bounded by disk, not memory. Decide in-task: modest retention (e.g. `3d`) on ephemeral storage vs enabling the small PV for restart-survival; the local-path provisioner exists on prod.
- Dashboard presets live in `metrics-filters.tsx` (30m / 1h / 12h buttons). Render's picker defaults to Last 12 hours with more granularity (3h/6h/1d).
- Argo auto-syncs the values change; verify on prod after a few hours that a >3h range draws data past the old horizon.

## Steps

1. Raise `retention` (and decide PV) in `deploy/gitops/base/prometheus.yaml`; run `scripts/gitops-validate.sh`.
2. Add 3h/6h/1d presets to the range picker, mapping to sensible `resolution` steps (keep ≤ ~121 points per chart like today).
3. After ship + a soak window, confirm a 6h range on prod shows >3h of history.

## Files

- `deploy/gitops/base/prometheus.yaml`
- `dashboard/src/features/metrics/components/metrics-filters.tsx`

## Acceptance criteria

- [ ] `gitops-validate.sh` green; Argo syncs the retention change.
- [ ] New presets render and query with proportional resolution.
- [ ] (Post-soak) a range wider than 3h shows data beyond the old retention horizon on prod.

## Out of scope

- Long-term/durable metrics storage (Thanos/Mimir class work); billing-grade month figures.
