Where does the data on this page come from?
Nothing here is typed by hand. The page reads SonarCloud for the quality gate, coverage, code smells, complexity and lines of code, and the GitHub API for CI runs, releases, commits, stars and forks. The OpenSSF Scorecard result comes from api.securityscorecards.dev, and the dependency figures from a daily report of the repository's npm audit and open Dependabot pull requests. Your browser fetches the same JSON endpoints listed above, which any script can call without a key.
How fresh are the numbers?
The quality gate and the latest CI run are cached for two minutes, the release and the newest commits for ten, the quality gate conditions and complexity hotspots for ten, the history charts and the coverage of each plugin for thirty, and the project figures for an hour. The dependency report runs daily and on every push to master. If a source stops answering, the page shows the last known value with its age instead of passing it off as current.
What do the four states mean?
Ready means every check passed for the commit CI last built. Pending (amber) means nothing has failed, but either a CI run is still going or SonarCloud has not scanned that commit yet, which clears by itself within about ten minutes of a push, or SonarCloud still lists open findings such as code smells, which stay until they are fixed. Unknown (grey) means GitHub or SonarCloud did not answer, or answered with something this page cannot use, so the last known values are shown with their age and there is no current answer. Not ready (red) means a check failed. A source that does not answer is never shown as passing or failing.
How much static analysis does the code go through?
Every push to master and every pull request runs several independent analyzers. The C# build treats compiler warnings as errors and runs the Sonar rule set next to the Roslyn analyzers, so a violation fails the build. SonarCloud then analyses the C#, the TypeScript and the other languages, and its quality gate has to pass. CodeQL scans the C# and the JavaScript and TypeScript on each push and pull request, and again every week, because new queries find problems in code that has not changed. Gitleaks scans for committed secrets, and GitHub's own secret scanning watches the repository as well. OpenSSF Scorecard checks the project's settings and practices on each push and weekly, and Dependabot proposes dependency updates weekly for NuGet, npm, GitHub Actions and Docker images.
What does the quality gate check?
The gate is SonarCloud's, and it is evaluated on new code. The conditions listed under Quality gate conditions require the reliability, security and maintainability ratings of the code added since the baseline to stay at A, so a change that introduces a bug, a vulnerability or heavy technical debt turns the gate red. The CI job waits for the gate, which means a failing gate fails the build.
How is test coverage measured?
Every plugin has its own test project, CI runs all of them with dotnet test on the whole solution, and the dashboard has its own tests. The coverage is reported to SonarCloud, which produces one figure for the whole project. The backend figures on this page are that project figure minus the dashboard, counted in lines and branches, and the dashboard is shown on its own under Dashboard coverage; the breakdown under Coverage by plugin covers the plugins. Coverage tells you which lines the tests execute, not whether the tests check the right things.
How are dependencies and secrets checked?
Dependabot opens weekly pull requests for NuGet packages, npm packages, GitHub Actions and Docker base images. A daily workflow runs npm audit on the dashboard's lockfile, and the result is shown under Dependencies. The GitHub Actions and the Docker base images are pinned by hash, so a tag that is moved later cannot swap in different code. Gitleaks and GitHub secret scanning look for committed credentials.
What does the file count mean?
GitHub only lists the first 300 files of a comparison, so a very large gap shows as 300+. The commit count is exact.
Why do the quality charts start so recently?
SonarCloud only keeps the scans it has run. The coverage and smell history begins with the first scan; the commit and churn charts come from GitHub and go back years.
Is this the released version or master?
Master. The release is shown only as the baseline to compare against, so you can see how far master has moved since the version you may be running.
Does this show the health of my own cloudlet?
No. It shows the health of the open-source code on master, not of an installation. To compare, check your cloudlet's version against the latest release under Master vs the latest release. The number of commits ahead tells you how far master has moved since that version.
Can a script or an AI agent read this instead of the page?
Yes. Every number on the page comes from a JSON endpoint that needs no key, and the summary endpoint answers in one small object whether master is passing, failing or unknown. The page links all of them, there is an OpenAPI description at /openapi.json, and the agent entry point is at /.well-known/hyperlambda-agent.
Does a green page mean the code has no bugs?
No. It means the checks that run today passed: the compiler and analyzers, the tests, SonarCloud's gate, CodeQL and the secret scan. They find whole classes of mistakes but cannot prove that none are left, and coverage says which lines run in tests, not what the tests verify. A finding that one of these tools raises is either fixed or dismissed with a written reason in GitHub's code scanning, so it never just stays flagged without an answer.