UI dashboards are lagging behind (CI)

We are currently investigating this issue.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

# Summary

Between 25 July and 4 August 2026, pipeline execution dashboards and overview pages in the Harness Prod 2 and Prod 3 clusters displayed data that was between behind real time. Pipelines themselves continued to build, deploy, and execute normally throughout; the issue was confined to how quickly execution records were copied into the database that serves reporting and dashboard views.

‌

No customer data was lost. Every affected record remained durably stored and was replayed into the analytics datastore once the underlying limitation was removed. Harness migrated the affected clusters to a horizontally scalable, queue-backed version of the replication component on 1 August 2026 and completed targeted data backfills for all affected accounts.

# Root cause

Harness maintains a change-data-capture component that continuously replicates pipeline execution records from the primary operational datastore into a separate time-series datastore optimised for dashboards and reporting queries. Dashboards read exclusively from the analytics datastore. When replication falls behind, dashboards render an accurate but older view of the world, while execution itself is unaffected. This was caused by sharp, sustained increase in database write volume from another Harness platform module sharing the same replication path exceeded the throughput ceiling of the older, single-instance version of that component still running in Prod 2 and Prod 3. A backlog formed and grew.

‌

‌

# Preventive actions

Harness has completed or committed to the following actions to prevent such issues.

| Action |

| --- |

| Fine tune the replication lag alerting so that any delay beyond a defined threshold is notified |

| Add a replication lag panel to the standard platform monitoring board so pipeline health is visible to on-call by default |

| Reduce write amplification from co-tenant modules through per-module rate limiting or entity filtering on the replication stream |