Diagnosing Missing, Stale, or Duplicated Rollups in InfluxDB

After adjusting retention or downsampling settings, InfluxDB dashboards and alerts can start showing empty rollup series, stale timestamps, or duplicated points—while raw data may disappear earlier than expected. The useful takeaway: these symptoms almost always trace back to one of four root causes—retention shorter than the query window, a failed or paused aggregation task, overlapping or replayed backfills, or schema conflicts during writes. Work through the checks in order; changing retention or rerunning tasks before confirming the cause usually duplicates data or deletes more of it.

Recognizable Condition

You are likely dealing with a lifecycle or aggregation problem when a dashboard or alert that previously worked begins to show one or more of the following after a configuration change:

• Gaps in downsampled or continuous-aggregation data where raw data used to exist.
• Stale rollups whose newest timestamp is older than the current schedule interval.
• Duplicated points in the rollup bucket or database, inflating counts or sums.
• Raw data vanishing earlier than the documented or intended retention period.

Cause and Diagnostic Map

Symptom	Likely cause	Diagnostic
Raw data gone early	Retention shorter than query window	Compare configured retention with requested time range
Rollup empty or stale	Task or continuous query failed, paused, or mis-scheduled	Check run status, logs, last success, and next run
Rollup duplicates	Overlapping runs or replayed backfill	Compare counts by window and inspect run history
Schema or type conflict	Field type change or renamed measurement	Validate line protocol and write errors

Ordered Checks

1. Confirm the target bucket or database and its retention. In InfluxDB 1.x, run SHOW RETENTION POLICIES ON <database> in the Influx shell or CLI with read access; the expected result is a duration that matches your intended window. In 2.x, use influx bucket list or the UI with an All-Access or Read token. In 3.x, use the deployed version's catalog or lifecycle view—naming and controls differ. Compare that retention with the time range your dashboard or alert requests. If the retention is shorter than the query window, raw data will legitimately be absent; the rollup must cover the gap.

2. Reproduce with a narrow time range and explicit precision. Query a one-hour window where the gap appears. Use explicit timestamps (for example, RFC3339 or epoch milliseconds) rather than relative UI ranges to rule out timezone drift. In 1.x InfluxQL, use WHERE time >= <start> AND time < <stop>; in 2.x Flux, use range(start: <start>, stop: <stop>).

3. Inspect task or continuous-query health. In 1.x, run SHOW CONTINUOUS QUERIES (read-only) to confirm the CQ exists and is enabled. In 2.x, list tasks with influx task list, then inspect logs with influx task log --task-id <task-id> using a token with read or all-access permissions. Look for the last successful run, the next scheduled run, and any error text. In 3.x, check the processing-engine plugin or task status through the deployed interface. A paused task, a schedule offset that skips the final partial window, or a recent query error explains stale or empty rollups.

4. Compare raw versus rollup counts for the identical window. Run a count aggregation against both the raw and the rollup target for the same bounds. If raw returns rows and the rollup does not, the aggregation layer is suspect. If both are empty, suspect retention or the write path. If the rollup returns more rows than the raw source for the same logical window, suspect duplication.

5. Validate writes and schema for the affected period. Inspect line protocol and write-error logs for field type changes or measurement renames. A field that changed from integer to string, or a measurement that was renamed, can cause points to be rejected or stored under a different series, leaving the rollup query blind to them.

6. Check clock, timezone, and late-arriving data. Compare the task schedule offset with the typical data arrival lag. If telemetry arrives after the task has already closed its window, the rollup will have a permanent gap unless the task supports late data or you run a targeted backfill.

7. Only then change retention or rerun. Extending retention increases storage and query cost; shortening it deletes data that may be needed for audit. Backfills can duplicate data if the destination is not idempotent. Confirm the cause first.

Fixes Tied to Findings

• Retention is too short. Extend retention or add a downsampling task that runs before raw data expires. Rollback: if you later shorten retention again, data outside the new window is deleted; there is no undo.
• The task failed. Correct the query or schedule, then backfill only the missing windows. Rollback: if the backfill duplicates points, delete the duplicated window or restore from a backup.
• Duplicates appeared. Make the run idempotent (for example, by deleting the destination window before writing) or deduplicate before re-running. Rollback: remove the duplicated points from the rollup target.
• Schema conflicts occurred. Correct the line protocol or use a compatible field type. Rollback: InfluxDB does not generally reverse schema changes without rewriting the affected data.
• Time bounds are wrong. Align the schedule offset and the query range so the rollup window covers the full requested period.

Concrete Diagnostic Decision

Suppose a dashboard queries a 7-day rollup, but the raw bucket retention is 3 days and the downsampling task runs hourly. After 3 days, raw data expires, yet the rollup should still cover the full 7 days if the task ran successfully. If the rollup also stops at 3 days, the task likely failed or its schedule offset excludes the final hours. If the rollup covers 7 days but shows duplicated points, overlapping task runs or a replayed backfill is the likely cause. This single comparison—retention boundary versus rollup coverage—often resolves the incident without touching configuration.

Escalation Criteria

Escalate to your platform or database team when:

• Data loss spans multiple buckets or databases and retention settings cannot explain it.
• Object-store or catalog errors appear, or the process repeatedly runs out of memory.
• Task failures persist after you have applied and verified a fix.
• Missing data affects billing, compliance, or production alerting.

Limitations and Verification

InfluxDB 1.x, 2.x, and 3.x differ in buckets, databases, query languages, and lifecycle controls. Do not infer support from version numbers alone: 1.x uses retention policies and continuous queries with InfluxQL; 2.x uses buckets, tasks, and Flux; 3.x uses different lifecycle and query naming and may expose processing-engine plugins. Exact task syntax, retention controls, and cardinality or memory limits are version-specific—verify them against the deployed instance.

To verify a fix safely, reproduce the issue on a staging instance with a copied bucket or database. Run the same narrow query before and after the change and compare row counts and minimum/maximum timestamps. Inspect the task or continuous-query run history and logs for the exact window to confirm last success, next run, and error text. Validate retention by querying the oldest retained point and comparing it with the configured retention, then confirm the rollup output covers the same range. Check resource behavior during the query or task run using the platform's own metrics and logs rather than assumed thresholds.