Repository navigation
[Bug]: Backup status does not set startedAt until backup completes #9352
Description
Is there an existing issue already for this bug?
- I have searched for an existing issue, and could not find anything. I believe this is a new bug.
I have read the troubleshooting guide
- I have read the troubleshooting guide and I think this is a new bug.
I am running a supported version of CloudNativePG
- I have read the troubleshooting guide and I think this is a new bug.
Contact Details
No response
Version
1.27 (latest patch)
What version of Kubernetes are you using?
1.34
What is your Kubernetes environment?
Self-managed: kind (evaluation)
How did you install the operator?
YAML manifest
What happened?
Currently, CloudNativePG does not set the .status.startedAt field on Backup resources until the end of the backup when it also sets the .status.stoppedAt field.
This makes it challenging to effectively monitor long-running backups. Users have no way to know when a backup actually started processing.
Root Cause
The startedAt and stoppedAt fields are a mix of when the operator starts processing and when the backup tool finishes. There is no clear separation between:
- When the operator starts reconciling the backup
- When the actual backup tool started/stopped execution
Proposed Solution
Separate the two concepts by introducing new fields:
- reconciliationStartedAt: Set when the operator begins processing the backup
- reconciliationTerminatedAt: Set when the operator finishes processing (either successfully or with failure)
The existing startedAt and stoppedAt fields should be reserved for the backup tool's actual execution times.
Cluster resource
Relevant log output
Code of Conduct
- I agree to follow this project's Code of Conduct
Reacted by dosubot
Activity
dosubot commentedon Dec 2, 2025
You’re correct—CloudNativePG currently sets the .status.startedAt field on Backup resources only after the backup tool completes, at the same time as .status.stoppedAt. This means there’s no way to track when the operator actually began processing the backup, which makes it hard to monitor long-running backups in real time. The documentation and code confirm that startedAt and stoppedAt are tied to the backup tool’s execution, not the start of operator reconciliation, and there are no fields like reconciliationStartedAt or reconciliationTerminatedAt to distinguish these phases (reference).
This gap hasn’t been addressed in issues, code, or docs so far. Some related discussions (like #7812 and #9161) talk about backup monitoring and metrics, but not about separating reconciliation and backup execution timestamps.
If you need to monitor backup progress with the current implementation, the best workaround is to use kube-state-metrics to expose Backup resource status fields (including startedAt and stoppedAt) as Prometheus metrics. This lets you alert on backup status changes, but you still won’t see when the operator started processing the backup—only when the backup tool actually started and finished (example).
Your suggestion to add reconciliationStartedAt and reconciliationTerminatedAt fields would fill this gap and improve monitoring. This change isn’t present in the codebase or discussed in the project so far, so it would be a new feature and likely require a design discussion with maintainers.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
[-][Bug]: Backup status does not set startedAt until backup completes, making monitoring difficult[/-][+][Bug]: Backup status does not set startedAt until backup completes[/+]fix(backup): add reconciliation timestamps to backup status (cloudnat…