> For the complete documentation index, see [llms.txt](https://docs-lunar.earthly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-lunar.earthly.dev/sql-api/views/bypassed-checks.md). # bypassed\_checks Schema reference for the bypassed\_checks SQL view, an append-only log with one row per occasion a bypass let a failing or pending check through. ``` bypassed_checks ``` The `bypassed_checks` view provides information about the checks each bypass has let through, with one row for every occasion it happened. The [`bypasses`](/sql-api/views/bypasses.md) view records what a bypass was scoped to, while this view records what it actually masked. The two can differ, because a bypass with a `NULL` `policy` covers every blocking check on its gate, including checks from policies added to the manifest after the bypass was created. ## Schema | Column | Type | Description | | -------------- | ----------- | --------------------------------------------------------------------------------------- | | `id` | `TEXT` | The identifier for this masking occurrence | | `bypass_id` | `TEXT` | The identifier of the bypass that masked the check. Join to `bypasses.id` | | `component_id` | `TEXT` | The identifier for the component whose check was masked - e.g. `github.com/foo/bar/buz` | | `gate` | `TEXT` | The block the check was masked in. Can be one of `pr` or `release` | | `sha` | `TEXT` | The Git commit SHA the masking happened on | | `pr` | `BIGINT` | The pull request number the masking happened on. Set to `NULL` outside a pull request | | `check_name` | `TEXT` | The fully qualified name of the check - e.g. `sbom.no-critical-vulns` | | `masked_at` | `TIMESTAMP` | The UTC timestamp of this masking | ## Notes * The view is an append-only log. Every masking writes its own row and no row is ever updated, so "how many times" and "when was the last one" are `count(*)` and `max(masked_at)` at read time rather than stored columns. * **A row is written where a gate's verdict is consumed to let something through, not where it is reported.** For the PR gate that moment is the merge: a bypassed pull or merge request that is still open, or that was closed without merging, has no rows even though the bypass was clearing its checks the whole time. For the release gate it is the `lunar policy ok-release` call. Posting a check run or status, re-evaluating a gate, and `lunar policy ok-pr` all write nothing. A check still pending at merge is recorded too, when a commit-bound bypass with no `policy` covered the commit, the only kind of bypass that lets a pending check through. * A bypass that was never exercised has no rows in this view. ## Usage examples Retrieve the checks that a given bypass has let through. ```sql SELECT check_name, sha, min(masked_at) AS first_masked, max(masked_at) AS last_masked, count(*) AS times FROM bypassed_checks WHERE bypass_id = '00000000-0000-0000-0000-000000000000' GROUP BY check_name, sha ORDER BY first_masked; ``` Retrieve the active bypasses that have masked at least one check, along with who created them. ```sql SELECT b.component_id, b.actor, b.reason, bc.check_name, count(*) AS times, b.expires_at FROM bypassed_checks bc JOIN bypasses b ON b.id = bc.bypass_id WHERE b.active GROUP BY b.component_id, b.actor, b.reason, bc.check_name, b.expires_at ORDER BY max(bc.masked_at) DESC; ``` Retrieve the bypasses that never masked anything. On the PR gate this includes every bypass whose request has not merged yet. ```sql SELECT b.component_id, b.actor, b.reason, b.created_at, b.expires_at FROM bypasses b LEFT JOIN bypassed_checks bc ON bc.bypass_id = b.id WHERE bc.bypass_id IS NULL ORDER BY b.created_at DESC; ``` Retrieve the checks that were first masked more than two days after their bypass was created, which indicates a bypass that started covering something new. ```sql SELECT b.component_id, bc.check_name, b.reason, min(bc.masked_at) - b.created_at AS granted_to_first_mask FROM bypassed_checks bc JOIN bypasses b ON b.id = bc.bypass_id GROUP BY b.component_id, bc.check_name, b.reason, b.created_at HAVING min(bc.masked_at) > b.created_at + INTERVAL '2 days' ORDER BY granted_to_first_mask DESC; ``` Retrieve the most frequently masked checks across all components. ```sql SELECT check_name, count(DISTINCT bypass_id) AS bypasses, count(*) AS total_maskings FROM bypassed_checks GROUP BY check_name ORDER BY bypasses DESC; ``` --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs-lunar.earthly.dev/sql-api/views/bypassed-checks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.