> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/coverage-analysis-and-reporting/coverage-refresh-cadence.md).

# Coverage Refresh Cadence

Coverage in an active test cycle updates automatically as test results are reported to SeaLights — approximately every 15 minutes. There is no manual refresh step, no nightly batch job to wait for, and no need to re-run the analysis after tests execute. The coverage report reflects the current verified state of the cycle at all times during its active window.

***

### Business Value & Key Use Cases

* **Live release readiness visibility** — Release managers can check coverage at any point during a test execution window and see an accurate picture of what has been verified, without waiting for an end-of-day report or asking the QA team for a status update.
* **Mid-cycle decision making** — If coverage reaches an acceptable threshold before all planned tests have run, the team has the data to make an informed go/no-go decision mid-cycle rather than waiting for the full execution to complete.

***

### Detailed Functionality

#### What Triggers a Coverage Update

A coverage update occurs when SeaLights receives new execution results and processes them against the cycle's dependency model. The update recalculates:

* Which most-at-risk executables are now confirmed as covered
* Which changed objects have been observed as exercised
* Which entries in the Test Gaps are now resolved
* The overall coverage percentage at each level (App Area, Executable, Object)

The update does not change the test recommendations (the Tests to Run list is fixed at cycle creation), the Most-At-Risk set, or the Change Analysis metrics. Only coverage state changes.

#### After a Cycle Is Closed

Once a cycle is closed, coverage stops updating. The coverage record is locked at the state it was in at the moment of close and retained permanently. No further test results — even if reported after the close date — are applied to the closed cycle's record.

This behavior is intentional: a closed cycle represents a finalized, auditable record. Allowing post-close updates would make the record mutable and undermine its value as evidence.

***

### FAQ

**Q: Can we force an immediate coverage refresh?** A: No. The refresh cadence is automated and cannot be manually triggered. \[Configuration detail pending validation — whether an on-demand refresh option is planned for a future release.]

**Q: We closed the cycle before all test results were reported. Can those results be applied retroactively?** A: No. Closing a cycle locks the coverage record permanently. Results reported after close are not applied to the closed cycle. If tests are still running, keep the cycle open until all results have been received and coverage reflects the final state.

**Q: Does coverage refresh affect the Test Gaps in real time too?** A: Yes. The Test Gaps updates within the Coverage Analysis. As tests execute and cover previously gapped objects, those objects leave the gap list within the next refresh window.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/coverage-analysis-and-reporting/coverage-refresh-cadence.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.