Skip to main content

​
“Completed” means the check ran — not that you passed

In Data Library → Tests, the Status column shows one of six pills: Completed, Failed, Error, In Progress, Not Run, Deactivated. Completed means DSALTA reached your system, collected the data, and finished evaluating the check. On its own it does not mean the check found nothing wrong. A check that ran perfectly and found five misconfigured resources is still Completed, because the run succeeded. Failed does not mean “you are non-compliant” either. It means DSALTA was blocked and could not evaluate the check at all — almost always a missing permission, or a setting it still needs from you. To see what a check actually found, open it and read the result code.

​
Where to find the result code

1

Open the test

Go to Data Library → Tests and click the test’s row. A panel opens on the right.
2

Go to Source Data

Open the Source Data tab. The table at the top lists the most recent runs, newest first, at most ten of them. Its heading reads API Requests on an integration test and Run History on a system test.
3

Read the Status column

Each run shows a numeric result code. It renders as a bare colored number with no caption, so use the table below to read it.
If the test has never run, there is no table at all — the tab reads No Source Data Found / “Run the test to collect source data and evidence.”
Underneath the run table, the Evidence panel shows the latest completed run as JSON. It is an envelope DSALTA builds around the run, not the stored result verbatim: method, passed, result, error, source and timestamp, with everything the check actually returned nested under result. Read result.summary first; where the check produced them, result.findings lists the specific offending items and result.remediation explains the fix.
The rows in the run table are runs, not resources. Ten rows means ten executions of the check, not ten findings. Individual offending resources live inside a single run’s findings list.

​
What each code means

​
The one thing to watch: 207

For checks powered by a connected integration, a 207 run still shows as Completed in the Tests list. That is deliberate — the run succeeded. But 207 means there is an open compliance gap, and the Tests list will not turn red for it.
Practical rule. Read the Tests list as “did the check run?” and the Source Data code as “what did it find?”. Review your 207 runs on a schedule. Do not wait for the Tests list to turn red — for integration-powered checks it never will.

​
403 and 428 are the only codes that turn the list red

Both mean DSALTA is blocked, not that you failed. They surface as Failed. A 500 also surfaces as Failed rather than as Error — so a red Failed pill on an integration check is a prompt to read the code before assuming a compliance problem.

​
Uploaded evidence overrides the run

If you attach evidence to a test manually, DSALTA records a passing result for it: on an integration-powered test a 200 row joins the API Requests list and the status holds at Completed through later runs, even when the automated run behind it fails; on a DSALTA system test the status flips to Completed straight away and the next daily system-test run restamps it with the handler’s own verdict, so read the Evidence tab for what you uploaded and the Run History rows for what the check itself found. Check for result.evidenceSource: "manual_upload" in the Evidence panel before taking a 200 as proof the automated check succeeded.