Quality Execution History
Quality Execution History shows recent quality-check runs across the current space. Use it when you need a space-wide audit trail of what ran, what passed, what failed, and which source check needs investigation.
When To Use It
Use the execution history page to:
- Review recent check activity across all products in a space.
- Find failed, warning, or error runs without opening each check.
- Confirm whether scheduled or externally pushed results are arriving.
- Open the source quality check before changing thresholds, rerunning checks, or excluding a test run from statistics.
- Support incident, alert, or governance review with a chronological run list.
For deep inspection of one check, open the source check detail page. That page shows expanded execution details, executed SQL, field-check results, reconciliation values, messages, and the ignore/include action.
Open The Page
Navigate to Quality -> Execution History. The page is scoped to the currently selected space and loads executions in pages of 50.
The URL can preserve filter state with query parameters:
| Parameter | Meaning |
|---|---|
q | Search text. |
status | Selected status filter, such as PASS, FAIL, or WARNING. |
time | Selected time filter, such as 24h, 7d, or 30d. |
Summary Cards
The cards at the top summarize matching execution activity:
| Card | Meaning |
|---|---|
| Recent runs | Total executions in the current filter context. |
| Passed | Runs that passed. |
| Failed | Runs that failed. |
| Warning | Runs that completed with warning status. |
Ignored executions are excluded from statistics. You can include or exclude a run from the source quality-check detail page.
Filters
Use filters to narrow the page before investigating:
| Control | Use it for |
|---|---|
| Search | Find runs by quality check name or triggering user. |
| Status | Focus on all runs, passed runs, failed runs, or warning runs. |
| Time range | Show all time, the last 24 hours, the last 7 days, or the last 30 days. |
Filters are useful during triage because they help separate one-off manual test runs from repeated scheduled failures.
Execution Table
Each row represents one execution.
| Column | Meaning |
|---|---|
| Status | The run outcome. Passing rows are healthy; failed, warning, and error rows need review. |
| Check name | The source quality check and short execution identifier. |
| Type | The quality check type, such as SQL, freshness, null, uniqueness, range, reconciliation, field, or custom. |
| Triggered | The execution timestamp. |
| Result | The raw status label returned by the check. |
| Action | Opens the source quality check detail page. |
Use Previous and Next to page through execution history. When the table is empty, either no executions exist yet or the current search and filters are too narrow.
Investigation Workflow
- Filter to
FAIL,WARNING, or the relevant time range. - Open the source check from the action column.
- Review the check detail page for actual value, execution message, query or field details, triggering user, and recent trend.
- Decide whether the result represents a real data issue, stale threshold, source-system problem, or test run.
- If it is a test or known invalid run, exclude it from statistics on the source check detail page.
- If it is a real issue, follow the linked alert, create a ticket, adjust the check, or rerun the check after remediation.
Ignored Executions
Ignored executions are excluded from quality statistics. Use this carefully for test runs, backfills, or known-invalid executions that should not change product health, dashboard metrics, or trend calculations.
You can ignore or re-include a run from the source quality check detail page:
- Open the source check from Execution History.
- Find the run in the check's execution history.
- Use the include/exclude action on the run.
- Recheck the statistics and trend after the page refreshes.
Do not ignore a failed production run just to improve the dashboard. Fix the data, threshold, schedule, or connector issue instead, then leave the historical failure as evidence.
Troubleshooting
No executions are listed means the space has no runs yet, the selected space is wrong, or the current filters hide all results. Clear the filters or run a check manually.
A scheduled check is missing usually means the check is disabled, the cron schedule has not fired yet, or the runtime could not execute the check. Open the check detail page and review its configuration.
A pushed external result is missing means the external job may be using the wrong space slug, check slug, API key, or result endpoint. Verify the job against the slug-based API shown in the Quality Checks guide.
A failure keeps returning means the underlying data, threshold, query, or connector still needs remediation. Open the source check and compare recent execution messages before changing the check.
Related Guides
- Quality Checks for check configuration, check details, manual runs, ignored executions, and external push workflows.
- Quality Dashboard for aggregate health, pass rate, trend, and product breakdown views.
- Alerts Center for alert triage and escalation.
- Continuous Monitoring for drift and monitoring workflows that rely on execution history.