run #4f1a9c
1 failure detected Step 1 of 3
Tests in plain English, owned as code.
Blop is the QA peer for teams that ship with coding agents. Describe a journey and an agent drives a real browser through it; the test lives as code in your repo, not as hidden state in a vendor dashboard. It runs in your CI, clusters the failures that repeat, and opens a pull request to fix the test when your UI moves.
Describe a test in plain English
Playwright-backed · Runs in your CI · Your tests, your repo
Setup
Point Blop at a repo. Test in minutes.
Connect a GitHub repo, pick the integrations your team already runs, and dispatch your first test from the dashboard. No runners to host.
YOUR DISPATCH CONSOLE
Run a test, connect a repo, search integrations
Step 1 / 3
Connect a GitHub repo
Authorize Blop on the repos you want to test. No runners to host, no personal access token in the browser. Blop authenticates with a per-project key your workflow holds.
Step 2 / 3
Pick your integrations
Add GitHub Actions, Slack, and Linear so tests dispatch, results post, and failures link out without glue scripts. Installed integrations surface everywhere they are relevant.
Step 3 / 3
Run from the dashboard
Name a suite and a target. Blop runs it on your CI, ingests the results, and surfaces failure clusters and synthetic uptime as one shared signal.
Plays nicely with
GitHub Playwright GitHub Actions Slack Linear CloudEvents OIDC
Tests as code
Real code in your repo, run by an agent.
A blop test is a .blop.ts file that reads like intent: "check out as a returning user with a saved card." An agent drives a real browser through it over Playwright. The test is version-controlled and reviewable, and one workflow file runs it in the CI you already have.
Intent-driven, not selector-coupled
Version-controlled and code-reviewed
One workflow file, no runners to host
blop.yml · the only thing added to your repo
- name: Run blop
uses: blopai/blop-action@v1
with:
suite: checkout
api-key: ${{ secrets.BLOP_API_KEY }}
Triage and healing
Failures cluster. Then the agent fixes them.
Identical failures merge into one cluster across every run, so a broken selector is one row, not thirty. Mark a cluster known, link it to GitHub or Linear, or let the agent open a pull request that fixes the test and verifies it green before you review. Auto-fix is in early access.
Identical failures merge automatically
Links out to GitHub and Linear
Agent-authored fix PRs (early access)
cluster #f3a2
Merged across 12 runs Step 2 of 3
blop/heal-f3a2
Opened and verified green Step 3 of 3
Wired into the stack you already run
Probes run on the schedule you set, watching the journeys your users depend on
Synthetic monitoring
Every test is also a synthetic check.
Schedule any test as a recurring journey probe against production. Uptime, p95 duration, and journey completion read as first-class signals, right next to pass and fail.
Any test becomes a probe
Uptime and p95 as first-class signals
Synthetic checks · last 24h 99.7% uptime
/checkout 99.6% 4.2s p95
/signup 99.8% 3.8s p95
/login 100.0% 1.4s p95
/dashboard 99.4% 6.1s p95
0.0%
rolling 24h uptime
0.0s
median journey p95
0
journeys on watch
The loop
Every result, and every fix, lands where you already work.
Runs post back to the pull request that triggered them. When the agent fixes a test, that arrives as a pull request too. Nothing changes in your repo without a diff you approve.
bb
blop-bot
2 minutes ago
Run #4f1a9c · 7 passed · 1 known failure
✓ checkout · 4.2s
✓ signup · 3.8s
✗ reset-password · 0.6s · cluster #f3a2 (known, linked GH#241)
Artefacts: trace.zip · console.log · screenshots/
Every run posts a structured comment to the originating pull request. Pass counts, failure clusters, artefact links, and known-failure context. The reviewer sees what they need to ship it or send it back.
No glue scripts
Every agent change is a reviewable PR
FAQ
The questions teams ask first.
The honest answers about tests, the agent, runners, and what Blop will not do yet.
Where do my tests live?
In your repository, as .blop.ts files. They are version-controlled, code-reviewed, and yours to edit or delete. Blop never keeps your tests as hidden state in our dashboard, so you can always read them, blame them, and take them with you.
Do I have to write the tests myself?
You can, and the framework is built for it: a blop test is plain intent in a .blop.ts file. An agent that crawls your app and proposes scenarios for you is in early access. Either way, the artifact is code you own.
How does the agent fix a failing test?
When a run fails, the agent inspects the failure, the trace, and the diff, then opens a pull request with a fix scoped to allowlisted paths and runs a verification build before you look. Nothing merges without your approval. Auto-fix is in early access.
Do I need to host my own runners?
No. Blop runs through your existing GitHub Actions runners (cloud or self-hosted). The control plane never executes your tests itself.
How does Blop see my secrets?
It does not. Runs authenticate with a per-project key your workflow holds, and the agent works in a disposable sandbox that cannot read .env files, CI config, or billing. Secrets never reach the browser, the traces, or the model prompts.
Does it only work with Playwright?
Playwright is the runtime today and is first-class. The result payload is a versioned contract, so other frameworks can emit it too; adapters ship next. Self-hosting the full control plane is on the roadmap, not yet shippable.
See your first test run in ten minutes.
Free in early access. No credit card. Your tests stay as code in your repo from day one.