Confirms the configured API key works and lists the organizations it can reach. Read-only and safe to call first when diagnosing setup. Returns each organization's id — export the one you want as GHOST_INSPECTOR_ORG_ID to enable on-demand validation runs.

Read-only tour of the whole account: every folder, the suites inside it, and per-suite counts of passing / failing / module / not-yet-run tests, plus the names of the failing ones. Start here — no other question about this account can be answered without knowing what is in it.

Import-only tests (modules: shared steps that other tests import, the equivalent of a function) are counted in their own bucket and never as failures. Marking a test import-only deletes its stored results, so every module looks permanently unrun; folding that into a failure count invents breakage that does not exist and aims cleanup at the steps the live tests all share. Read the notes field before drawing conclusions.

Fetches roughly 440 KB from the API and returns a summary of it, so ask for the whole account rather than probing folder by folder. Totals always describe the entire account even when a filter narrows the listing.

Answers the one question the API cannot: if I edit this module, which tests break? Builds the reverse index of execute steps — for every imported test, its direct importers and its full transitive blast radius through nested chains. Run this BEFORE editing any module.

Also surfaces three things that only appear once the index exists: import-only tests nobody imports (dead, or a test that lost its caller and is silently not running); imported tests NOT flagged import-only, which run standalone and inside their importers, so an edit changes both paths; and execute steps pointing at ids that no longer exist.

🔴 It also finds vacuousTests: tests that execute no steps at all, because their definition is only execute calls and the chain bottoms out in empty modules. Those pass — nothing can fail — so the dashboard shows them green while they assert nothing, which is worse than a red test and invisible any other way. Emptying one shared module does this to every test that imports it.

This is the expensive tool. steps is absent from the test listing, so it costs one request per test in the account — a few seconds for a few hundred tests, at deliberately low concurrency because the rate limit is undisclosed. Call it once and work from the result rather than per module. A definition that cannot be read is counted in scanned.unreadable, never skipped silently, because a missing definition understates a blast radius.

Call this BEFORE diagnosing or editing any red test. Splits failures into two piles by comparing the whole execute chain's dateUpdated against each test's last run.

staleFailures are red tests whose definition or module chain changed AFTER the failing run. The failure describes a version that no longer exists — a colleague may already have fixed it and the test simply has not run again. Editing on top of one destroys their work, and Ghost Inspector keeps no version history of steps. One level deep is not enough here, because modules nest; the whole chain is walked.

genuineFailures have had no change since the failing run, so the failure still describes the current definition. Start there, oldest first.

🔴 Re-running is not free advice: many Ghost Inspector suites submit real forms against production. Confirm what a test does before triggering it.

Also reports the case nobody looks for: passing tests whose chain changed after their last run, whose green result describes the old definition and proves nothing about the current one. Import-only modules are excluded rather than evaluated, since they have no results to compare against.

Costs one request per test, a few seconds for a few hundred tests.

Runs a test definition through on-demand execution, which executes it and discards it — nothing in the account is created or changed. Use it to check that a selector chain still resolves before editing a test, and to check a definition you are authoring before saving it.

🔴 It drives a real browser against a real URL, so it is an action with real-world effects even though nothing is saved. Two guards apply and neither can be turned off. Modules are inlined first, because a test whose steps are just execute calls hides its submit inside a module and guarding the definition as written would miss it. Then the run is truncated at the first step that could submit a form, and that step is replaced by an assertion on the same target — so the whole chain is verified, including that the submit control is reachable, without ever activating it. There is no way to make this tool submit; that stays a deliberate curl.

For an existing test the suite's viewport and browser are replicated, because tests inherit those and a selector can resolve on desktop and fail on mobile. Read ranAs.configSource to see what was actually used.

A browser run takes 20-100 seconds; the tool polls until it finishes. passing: null in the raw API means not finished, never failed.