> 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/coverage-and-quality-insights/coverage-analysis/how-the-data-works.md). # How the Data Works Understanding how Coverage Analysis collects, calculates, and displays data helps you interpret your views accurately and avoid surprises when numbers don't match your expectations. *** ### Data Collection and Refresh SeaLights agents collect coverage data continuously as tests run across your environments and new versions of services are deployed. This data flows into SeaLights in real time, the agents are always on, capturing execution data whenever tests are triggered. Coverage Analysis views are recalculated automatically in the background every 15 minutes, as long as the view has been accessed within the last 30 days. This means the data reflects recent test activity and new deployed versions of services within a short window. The **"Data as of"** timestamp in the view header tells you when the last successful update occurred, so you always know how current the data is. Views that haven't been opened in over a month resume update the next time they are opened. When the view is opened on your browser for more than 15 minutes, simply refresh the page to see the latest update. *** ### Timezones Coverage data is stored internally in **UTC**. How that data is presented to you depends on the type of date range you have selected. #### Time-Window filters For ranges like "Last 8 Hours" or a specific time range like "Today 14:00–17:00", the window is calculated relative to your local time and then translated to UTC to retrieve the data. This means a user in California and a user in Berlin opening the same view at the same moment will both see the last 8 hours relative to their own local time, which maps to the same UTC window, so both users see identical results. #### Calendar-Day filters For fixed date ranges, "Current Week", "Previous Month", and similar calendar-based selections, data is retrieved purely based on the **UTC calendar date**. Your local time has no bearing on which days are included, day boundaries are always UTC midnight. This means the data you see may not align with what you expect if your local date differs from the current UTC date. #### What this means in practice This distinction matters most for teams in timezones that are significantly behind or ahead of UTC. A few examples: **Tests run late in the day in California (UTC-8)** If you run tests at 5:00 PM Pacific Time, that's midnight or later in UTC, which means those test results are attributed to the *next* UTC calendar day. If you're reviewing a fixed date range and wondering why late-afternoon test runs aren't showing up, this is likely the reason. **Tests run early in the morning in Tokyo (UTC+9)** If you run tests at 1:00 AM Japan Standard Time, that's still 4:00 PM the previous day in UTC. Those test results will be attributed to the *previous* UTC calendar day. If you're reviewing a fixed date range and a morning test run appears to be missing, it may be showing up under the day before in UTC terms. **Viewing "Previous Month" at the end of July in California** If it's July 31st on your local clock but UTC has already rolled over to August 1st, a "Previous Month" filter will show you **July 1–31**, because SeaLights sees the current UTC month as August and therefore treats July as the previous month. You won't accidentally see June data; the view correctly reflects the full month of July from a UTC calendar perspective. In all cases, the data is accurate, it's a matter of understanding which calendar day your test activity was attributed to based on UTC. *** ### App-Level Tests Are Always Included Some test stages, such as unit tests and component tests, run inside CI pipelines and are tied to a specific build or code commit, not to a deployment in a lab environment. These tests may have been executed days or even weeks before the team starts testing in a lab. Coverage Analysis automatically includes these app-level test coverage results in a view, **regardless of when the tests were run**, as long as the code they tested falls within your defined code scope. The date range you select does not filter out these results. This is intentional. For the typical Coverage Analysis audience, QA Engineers and QA Managers focused on what's been tested, it's often impractical to know exactly when a CI build ran or when unit tests were triggered. What matters is whether the code in scope was tested, not whether the tests happened to run during a specific calendar window. If you don't want a particular test stage included in your view, for example, if you want to focus exclusively on lab-based testing, you can deselect it in the Test Stages step when creating or editing the view. *** ### How Code and Code Changes Are Calculated #### Overall Coverage For Overall Coverage, SeaLights looks at the **latest version of each service** deployed on one or more labs within your selected date range, regardless of branch. This latest version is the code being evaluated, the methods it contains are what Coverage Analysis measures coverage against. This ensures the view reflects the most current state of each service during the period you're analyzing. #### Change Coverage Change Coverage compares two snapshots of your codebase to determine what changed: * **"Before" snapshot:** The latest version of each service found just *before* the beginning of your date range. * **"After" snapshot:** The latest version of each service deployed *within* your date range. The difference between these two snapshots is what counts as "changed code". This approach ensures that no change made during the date range is missed, even if a service was updated multiple times, the comparison captures the full delta from where things stood at the start. Coverage is aggregated across all versions deployed during the selected period. If a service was deployed multiple times, even from different branches, and a method was covered in an earlier version but unchanged in a later one, it is still counted as covered. Coverage follows the code, not the deployment. #### Change Coverage with a Specific Reference Date When you set the Code Changes baseline to a specific reference date (rather than the start of the date range), the calculation works as follows: * SeaLights looks for the latest version of each service **on that reference date**. * If no version is found on that exact date, it looks backwards to find the **latest version before that date**. * This snapshot is then compared to the latest version within the date range. This gives you precise control over what counts as "changed". Useful when you want to measure changes relative to a specific release, independently of the test data window. Or when the code changes and testing are done in different periods (e.g.: different sprints). #### Ignore/Include Rules Any Ignore/Include Rules you have configured in SeaLights are automatically respected in Coverage Analysis. No new builds or additional configuration required. *** ### Testing Time vs. Build Reporting Time Coverage Analysis is based on when testing happened — not when builds were reported. This is an important distinction from other SeaLights reports and dashboards. In most SeaLights reports, the selected date range refers to when builds were *reported* to SeaLights, testing can happen any time after that, and the data still appears within that range as long as it covers those builds. Coverage Analysis works differently: the date range refers to when *testing actually occurred*. If testing happened outside your selected range, it won't appear in the view (unless they are [App-Level Tests](#app-level-tests-are-always-included)), regardless of when the builds were reported. This makes Coverage Analysis a true reflection of your testing activity within a specific period, giving you a more accurate and intuitive picture of what was actually tested and when. *** ### Summary
TopicHow it works
Data collectionContinuous, via SeaLights agents
View recalculationAutomatic, every 15 minutes
Data storage timezoneUTC
Time-window filtersCalculated in local time, translated to UTC. All users see the same data
Calendar-day filtersBased on UTC calendar date; day boundaries are UTC midnight
App-level tests (unit, component)Always included regardless of when they ran, if the code is in scope
Overall Coverage - code evaluatedLatest version of each service within the date range, regardless of branch
Change Coverage - "before" snapshotLatest version of each service just before the date range start
Change Coverage - "after" snapshotLatest version of each service within the date range
Change Coverage with reference dateLatest version on the reference date (or before it if none found on that date), compared to latest within the date range
--- # 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/coverage-and-quality-insights/coverage-analysis/how-the-data-works.md?ask=&goal= ``` `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.