Developer Tools
Ghost Inspector
Connect your AI to Ghost Inspector
QA engineers, developers, and release managers run automated browser tests in Ghost Inspector, but working out which tests are failing, which are flaky, and whether a release is safe means reading results suite by suite. AI can summarize test health instantly, but only if it reports what the results actually show and only reruns tests when you ask.
Why it matters
Capabilities that matter most for Ghost Inspector
01
Ready-made API endpoints
Install 17 Ghost Inspector endpoints from the app store for suites, tests and results, ready to use straight away.
02
Test health across every suite
Summary and matrix lists roll pass and fail results up by suite and day, so flaky tests stand out.
03
Reruns only when asked
AI tools report what results show, within per-user security, and rerun tests only through approved actions.
Use cases
Example AI Use Cases for Ghost Inspector
scenario
-
When a Ghost Inspector suite fails for a known reason, the explanation usually lives in a chat thread or someone's head instead of on the run itself. The next person to see the failure investigates it again, or two people leave conflicting notes on the same run.
What popdock provides
--
Name the suite and give your explanation, and it finds the most recent failed run in the window, never a passing one. It reads existing comments on that run, and if someone has already said the same thing it quotes them and stops. You see the run date, its pass and fail counts, the tests that failed and the exact text to be posted, and the comment is added once only after you confirm. Your wording is posted as written.
Business outcome
---
Failed suite runs carry their explanation on the record, so nobody investigates the same known failure twice.
scenario
-
A Ghost Inspector account collects clutter: suites outside any folder, suites with no tests, empty folders, tests that never run on a schedule and data sources nothing uses. Nobody audits it because it means clicking through every folder, suite, test and data source one at a time.
What popdock provides
--
Name the organization and it reads its folders, suites, tests and data sources, then checks each housekeeping rule: loose suites, empty suites and folders, unscheduled tests, tests whose browser or region differs from their suite, mismatched screenshot settings and data sources with no rows. Every rule gets a line even when it is clean, and unscheduled tests are flagged without being called defects. It names the three findings to fix first. Nothing is changed and partial reads are flagged.
Business outcome
---
Your test account stays organized, with a clear short list of clean-up work instead of a vague sense of mess.
scenario
-
Pointing an existing Ghost Inspector test at staging or another browser means duplicating it, finding the copy, renaming it and editing its settings. Pick the wrong source, or edit the original by mistake, and the production test you rely on quietly breaks.
What popdock provides
--
Name the source test, the new name and optionally a new start URL and browser, and it confirms exactly one source test matches and the new name is free. You see every setting that will change and are told the copy lands in the same suite and schedule, and nothing happens until you confirm. It duplicates once, edits only the new copy, then reads it back to prove the settings took. The original is left untouched and the copy is not run.
Business outcome
---
You get a correctly retargeted test copy in one step, with the original guaranteed unchanged.
scenario
-
Working out why a Ghost Inspector test failed means opening the latest failed run, scrolling to the step that broke, reading what came before it and checking the browser console around that moment. Without that evidence people guess, and a timing issue gets logged as a product bug.
What popdock provides
--
Name the test and it finds the most recent failed run in the window, then reads the failing step and the full step sequence leading up to it. It checks the browser console for errors at that point and reads any comments already left so earlier analysis is quoted, not repeated. The report names the failing step and gives a best explanation as a product defect, timing problem or stale test. When the evidence is clean it says the failure is unexplained. Nothing in Ghost Inspector is changed.
Business outcome
---
You go from a red test to the step that broke and a likely cause, backed by real evidence.
scenario
-
Flaky Ghost Inspector tests erode trust in the whole suite, but they are hard to see because each failure looks like a one-off. Telling them apart from broken tests, or from failures limited to one browser, takes a run history nobody has time to assemble.
What popdock provides
--
Give a lookback period and a minimum number of runs, and it collects passing and failing results, keeping tests that did both and ignoring ones that always fail. It works out a flakiness rate, checks auto retry, screenshot comparison, browser and region, and looks at where the three worst break to tell timing problems from environment ones. Tests below the run floor are dropped and counted. Settings changes are recommended, not made.
Business outcome
---
Flaky tests are named with evidence and a mitigation, so the suite can be trusted again.
scenario
-
A Ghost Inspector suite can drift from reliable to noisy without anyone deciding to look. Judging its health means reading weeks of run results, working out whether pass rates and run times are trending the wrong way, and finding which tests cause it.
What popdock provides
--
Name the suite and a lookback period, and it reads every suite run in the window for pass rate, recent pass rate, median and worst run duration and runs with unknown results. It flags duration increases over 25 percent and groups failing test results to show which tests cost the most. It refuses to call a trend from fewer than four runs and checks the schedule when the suite has not run. Two or three recommendations close the report. It reads from Ghost Inspector but writes nothing back.
Business outcome
---
You see whether a suite is getting better or worse, and which tests to fix to turn it around.
scenario
-
After a fix is deployed, someone has to rerun the failing Ghost Inspector test, wait, and, if it still fails, dig into the steps again. Reruns get repeated in the hope of a lucky pass, and the context of the original failure is lost along the way.
What popdock provides
--
Name the test, with an optional start URL or browser, and it confirms exactly one test matches and shows what will run, warning that a run performs real actions on a live site. Nothing runs until you confirm, and the test runs once with no retries. A pass is reported with its run time against the previous state. A failure is diagnosed straight away with the failing step and related console errors.
Business outcome
---
You know whether a fix worked after one deliberate run, with the failure explained if it did not.
scenario
-
A slow Ghost Inspector suite delays every release, but it is not obvious which tests or which of their steps eat the time. Finding out means comparing run durations across days and then timing step by step through the slowest runs by hand.
What popdock provides
--
Give a duration threshold and a lookback period, and it finds runs over the threshold, then compares each test's median and worst duration to separate consistently slow tests from occasional ones. For the five slowest it times consecutive steps to name the two that take longest, with their command and target. Durations come only from recorded times, never estimates, and missing step timing is stated. Changes are recommended, not made.
Business outcome
---
You know exactly which steps to trim to shorten a slow suite, instead of guessing.
scenario
-
After a run of red results, the team needs to decide what to fix first, but a raw failure count rewards tests that run hourly. Sorting real breakages from occasional blips and brand new regressions takes a spreadsheet nobody has time to build.
What popdock provides
--
Give a lookback period, and optionally a suite, and it collects both failing and passing results so each test gets a failure rate, not a raw count. Tests are ranked from always failing, to high failure rate, to a new failure at the end of the window, to an old blip that has passed since. Browsers and regions affected are noted, and truncated windows are flagged. You get at most five recommendations on what to investigate first, and nothing is changed.
Business outcome
---
Your team starts on the failures that matter most, ranked by evidence rather than by noise.
scenario
-
After a deploy goes out, someone has to compare Ghost Inspector results before and after it to see what broke. Lining up test times against the GitHub workflow run, and then working out what shipped, is slow, so after a busy release it is often skipped.
What popdock provides
--
Name the GitHub workflow, and optionally a branch, and it finds the latest successful run and the one before it to set the windows. Ghost Inspector results either side are compared per test as regressed, fixed, still failing or not run since. For each regression it reads the failing step, and it lists the GitHub commits that shipped in the deploy. It ends with a verdict and says when the deploy was untested. Nothing in Ghost Inspector or GitHub is changed.
Business outcome
---
You know within minutes whether a deploy broke anything, and which commits shipped with it.
scenario
-
Deciding whether a release is ready means weighing the open GitHub issues on its milestone against the latest Ghost Inspector results, usually in a meeting with two browser tabs. Stale test results and test-failure issues that are already fixed muddy the call.
What popdock provides
--
Name the GitHub milestone, and optionally a suite filter, and it reads the milestone and its open issues alongside the most recent Ghost Inspector result for each matching suite. Open issues about test failures are checked against the current suite result, so a fixed failure reads as a close candidate, not a blocker. Results older than the latest closed issue are marked stale and suites with no results count as a risk. You get a Ready, Ready with risks or Not ready verdict with its reasons. It reads from Ghost Inspector and GitHub but writes nothing back.
Business outcome
---
Release decisions rest on current test evidence and the real open work, summarized in one verdict.
scenario
-
Turning a failed Ghost Inspector suite run into a GitHub issue means copying failing steps and console errors for each test, checking for an issue already open, and linking the two. Skip the check and the backlog fills with duplicate issues for the same broken suite.
What popdock provides
--
Give the suite result and an optional label, and it reads the failed run with each failing test's step and first console errors. It looks for an open GitHub issue already tracking that suite, and drafts either a new issue or a comment on the existing one. Nothing is written until you confirm the draft, and each system is written at most once. The suite result then gets a comment linking the GitHub issue, and if the new issue cannot be found again it does not create a second one.
Business outcome
---
Every suite failure is tracked in GitHub once, with the evidence attached and a link back from Ghost Inspector.
scenario
-
GitHub issues about Ghost Inspector failures stay open long after the tests pass again, while new failures go unfiled. Sorting it out means checking every open issue against current results, and every failing suite against the backlog, by hand.
What popdock provides
--
Give a title marker and a lookback period, and it reads open GitHub issues carrying that marker and checks each suite and named test in Ghost Inspector. Issues are sorted into now passing, still failing and not found, with ambiguous suite names listed rather than guessed. It then finds suites failing recently with no open issue. It ends with four tables, one per group, with the latest result times. Closing and filing are recommended, never done.
Business outcome
---
Your issue backlog matches reality: stale issues ready to close and real failures nobody has filed yet.
scenario
-
After a GitHub Actions deploy, someone should run the Ghost Inspector smoke suite against it, but first they need to know the build finished and passed. Running tests against a half-finished or failed deploy wastes runs and produces misleading failures that send people chasing the wrong problem.
What popdock provides
--
Name the workflow, optionally a branch, and the suite, and it checks the latest GitHub run has completed successfully, stopping if it is still running or failed. It shows which run and suite you are about to test, warns when the suite's start URL does not look like the deployed environment, and waits for confirmation. The suite runs once and failing tests are named. A one-line verdict says whether that commit passes.
Business outcome
---
Every deploy gets a smoke test only when the build is truly done, with a clear pass or fail verdict.
scenario
-
When a Ghost Inspector test starts failing, the first question is what changed. Answering it means finding the last pass and first failure, then listing GitHub commits and workflow runs in that gap, while allowing for the time zone differences between the two systems.
What popdock provides
--
Name the test and it finds the start of its current failing streak and the last pass before it. It lists the GitHub commits and workflow runs between those two times, comparing in UTC and widening the window when a time zone is missing. Commits whose messages mention the page or feature the test covers are marked as likely suspects, labelled as inference. When no commit falls in the window it points to data, environment or the test itself. It never claims a commit caused the failure and changes nothing.
Business outcome
---
You get a short list of suspect commits for a broken test, with correlation kept separate from cause.
scenario
-
Closing a GitHub issue about a test failure should rest on a fresh Ghost Inspector run, but finding the right test from the issue, running it and recording the result takes several steps. Issues get closed on a hunch, or sit open for weeks after the fix has shipped.
What popdock provides
--
Give the GitHub issue number, and optionally a test ID, and it reads the issue and its comments to find the Ghost Inspector test, stopping if none or several match. Nothing runs until you confirm the test, and it runs once. The result, with the failing step if it failed, is posted as one comment on the issue. A pass suggests the issue can close, but it never closes it, and it warns that one pass is weak evidence for a test known to be flaky.
Business outcome
---
Issue fixes are verified with a fresh test run and the evidence recorded right on the issue.
scenario
-
Jira bugs raised from Ghost Inspector failures stay open long after the test starts passing, because someone has to check each test's recent history first. The backlog fills with bugs that are really fixed, hiding the ones that still need someone's attention.
What popdock provides
--
Name the Jira project and a stable period, and it finds open bugs raised from Ghost Inspector failures and reads each test's runs in that period. A bug becomes a close-out candidate only with at least three runs that all passed, and bugs still failing or lacking evidence are listed separately. Duplicate bugs for one test are flagged. Verification comments are posted only if you ask and confirm the list. It never closes or reassigns an issue and never reruns a test.
Business outcome
---
Fixed bugs are flagged for closure with real run evidence, and the backlog shrinks to work that still matters.
scenario
-
Raising a useful Jira bug from a Ghost Inspector failure means copying the failing step, the console errors and the run details, then checking nobody has filed it already. Linking the bug and the test result both ways is the step that usually gets skipped.
What popdock provides
--
Give the test result and the Jira project, and it confirms the run really failed, then gathers the first failing step and console errors. It checks the result's comments and Jira for an open bug on the same test and stops if one exists. You see the summary and evidence, and nothing is written until you confirm. It creates the bug once, adds the evidence as a comment and a link to the result, and comments the Jira key on the test result. Any link that fails is named.
Business outcome
---
Every test failure becomes one well-evidenced Jira bug, linked both ways, with no duplicates.
scenario
-
Test failures pile up in Ghost Inspector while the Jira backlog tracks only some of them. Working out which failures nobody has ticketed, and which open bugs are for tests that now pass, means cross-checking every failing test name against the backlog by hand.
What popdock provides
--
Name the Jira project and a lookback period, and optionally a suite, and it groups recent Ghost Inspector failures by test so repeated failures count once. Each is checked against open Jira bugs, retrying with a shorter fragment before calling it untracked. It also finds open bugs whose test is no longer failing. When Jira returns nothing at all it checks the project key first. Nothing is created or changed in either system.
Business outcome
---
Untracked failures and stale bugs come out in one report, so nothing falls between testing and the backlog.
scenario
-
A suite's pass rate tells you something is wrong, but not whether anyone owns it. Seeing which failing tests have an open Jira bug and an assignee means combining weeks of run history with Jira backlog searches, one test at a time.
What popdock provides
--
Name the suite and the Jira project, and it reads the suite's runs for pass rate and direction, then each test's failure rate, showing a rate only with at least three runs. Every failing test is matched to open Jira bugs with status and assignee. You get a worst-first table, a note when failures sit on one browser or region, and a ranked list that puts untracked tests failing most of the time at the top. Nothing in Ghost Inspector or Jira is changed.
Business outcome
---
You see which failing tests have no owner, and fix the costliest gaps first.
scenario
-
A test that keeps failing often has history: earlier Jira bugs, comments with conclusions, and a known product issue behind it. Without that context people repeat an investigation someone already finished, and reach the same conclusion a second time.
What popdock provides
--
Name the test and the Jira project, and it reads the test's settings and run history and names the failure pattern as browser-specific, clustered in time or steady. It reads the latest failing step, console errors and any notes on the result. It then reads every Jira bug mentioning the test, the comment history of the latest one, and bugs about the page the failing step targets. Disagreements, such as a Done bug while the test still fails, lead the report. Causes are asserted only with evidence, and nothing is changed.
Business outcome
---
You start from everything already known about a failing test, instead of repeating work someone finished last month.
scenario
-
Before a Jira bug is closed, someone should rerun the Ghost Inspector test it came from and record the result. Finding that test from the bug, running it and writing up the outcome is tedious, so bugs get closed on trust and some of them come back.
What popdock provides
--
Give the Jira issue key and it reads the bug, finding its test from the summary, an earlier comment or a name you supply, and stops rather than guess when several tests match. It asks first if the bug is already closed. The test runs once, and if it fails the first failing step and console errors are collected. One verification comment goes on the bug, and an inconclusive run posts nothing. It never changes the bug's status.
Business outcome
---
Bug fixes are proven with a fresh test run before closure, with the evidence on the Jira issue.
scenario
-
Judging a website's health means opening Ghost Inspector to tally suite runs and failures, then switching to BugHerd to count open bugs by severity, then matching URLs between the two by eye. Pages that both fail tests and draw bug reports are easy to miss when the numbers live in separate tools.
What popdock provides
--
Name the BugHerd project and a lookback period, and it matches the project to its Ghost Inspector suites by site URL. It works out each suite's pass rate, latest result and most often failing tests, then reads the open BugHerd bugs and recent feedback. The report gives a healthy, at risk or unhealthy headline, puts pages with both failing tests and open bugs first, and lists gaps on either side. It is read-only: no tests are run and nothing is changed in either system.
Business outcome
---
One page by page health verdict for your site, combining automated test results and reported bugs, with nothing changed.
scenario
-
A nightly Ghost Inspector run fails and someone has to open each result, find the failed step, copy the console errors and write it up as a BugHerd task. Do that for every failure and you end up with duplicate tasks for the same test, or a screenshot change logged as a bug.
What popdock provides
--
Name the Ghost Inspector suite, the BugHerd project and a lookback period, and it finds the tests that failed and are still failing. For each it gathers the first failed step and up to three console errors, then checks BugHerd for a task already raised from that test and skips it. You see the tasks it will create and can remove any before you confirm. It then creates one task per approved test, with higher severity for home, checkout or login pages, and comments the task number on the failing Ghost Inspector result. Screenshot only failures are listed separately, and it never re-runs tests or accepts screenshots.
Business outcome
---
Every real test failure becomes one well documented BugHerd task, without duplicates or hand-copied evidence.
scenario
-
Before a release, someone has to start the Ghost Inspector suite, wait for it, read the failures, then go through BugHerd for open critical and important bugs and decide whether to ship. The test results and the bug list live in different tools, so the go or hold call often rests on whichever one was checked last.
What popdock provides
--
Name the Ghost Inspector suite, the BugHerd project and, optionally, a start URL, and it tells you which suite will run against which URL before anything starts. After you say yes it runs the suite once and reads the result and the failing tests with their first failed step. It then reads open critical and important BugHerd bugs and applies a clear rule: hold for any failing test or open critical bug, go with care when only important bugs remain, go when both are clear. It creates no BugHerd tasks, and a cancelled or errored run is reported as inconclusive.
Business outcome
---
A release go or hold decision backed by a fresh test run and the open bug list, made in one conversation.
scenario
-
BugHerd tasks raised from failing Ghost Inspector tests are easy to lose track of. A test starts passing but its task stays open, or a task is closed while the test still fails, and nobody notices until a client reports it again. Checking means opening each task and then its test's latest run.
What popdock provides
--
Name the BugHerd project, and it reads every task, including archived ones, that was raised from a Ghost Inspector test. For each it reads that test's latest result and sorts the pairs into fixed but open, closed but failing, and orphaned where the test no longer exists, with the pairs in step given as a count. Each table shows the task, its status, the test and the latest result date. It is read-only, so no tests are run and nothing is changed in BugHerd.
Business outcome
---
Catch closed bugs that still fail and open bugs that are already fixed, without opening a single test run.
scenario
-
When a developer says a bug is fixed, someone has to find the Ghost Inspector tests that cover that page, run them, read the results and then go back to BugHerd to close the task and note why. Without that, tasks either sit open for days or get closed without proof.
What popdock provides
--
Name the BugHerd project and task number, and it reads the task and finds the Ghost Inspector tests that cover it, either the test that raised it or tests whose start page matches the task's page. If none do, it tells you a manual retest is needed. It lists the tests and runs them only after you confirm. If every test passes, it proposes marking the task done with a comment naming the tests and date, and waits for a second yes. If any fail, it reports the failed step and leaves the task alone, and it notes when a passing test does not cover everything the task describes.
Business outcome
---
Close fixed BugHerd tasks with test evidence attached and keep unfixed ones open, in one conversation.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.