Stack

Test your Clerk sign-up and sign-in flow

Auth is the first thing every user touches and the last thing teams test by hand after setup. Here is how to have agents sign up, verify their email and sign in on every build.

5 agents try to .

How do I test a sign-up flow built with Clerk?

Have someone new sign up on the deployed app, verify their email, and reach the first screen after sign-in. Mimiq's agents do this in real browsers: each gets an email address with a working inbox, reads the verification code or link, and reports where it got stuck. To test pages behind sign-in, give the agents a test account; they type it on your site and on Clerk's hosted pages only.

Where auth flows fail

Redirects after sign-up that point at the wrong page or a localhost address, a verification step users do not notice, a required field the sign-up form hides on phones, an organization step nobody explained, and bot protection that blocks real people as well as bots.

  • Agents sign up with their own inboxes and read verification codes.
  • Hosted Clerk pages work: a test account is typed there too.
  • Redirect and session problems show as dead ends and failed requests.
  • Bot sign-up protection can stop agents: turn it off on the preview's instance.

How it works

  1. 01

    Give it a link and a task

    A preview, staging or the live app, and a task in plain words like "Sign up and start using it". No test scripts.

  2. 02

    Agents use it

    5 agents by default, each acting as a different one of your users in its own real browser, with a working inbox for verification emails.

  3. 03

    Read what they hit

    What broke, what the browser recorded (JavaScript errors, failed and slow requests), where each agent got stuck and why, with a screenshot of every step.

  4. 04

    Fix and rerun

    Run the same agents on the fixed build, by hand, from your coding agent, or on every preview deploy with the GitHub Action.

Sign-up, then sign-in

For a new-user check, the task is the sign-up itself: "Create an account and reach the dashboard." For pages behind sign-in, add a test account under Access (paid credits). The agents type placeholders; the real email and password are filled in only in the browser, and only on your site and on hosted sign-in pages such as Clerk's.

Bot protection

If bot sign-up protection is on for the instance the preview uses, agents can be stopped by its challenge. Any agent stopped by one is marked as blocked by the site, and if it stops every agent, the run fails and nothing is charged. A staging or preview address without bot protection works, as long as it is public or you give access.

Limits

Agents are simulated users. They find problems fast and on every build; they do not forecast how many real people will convert, they are not a deterministic regression suite, and they do not install native mobile apps.

40steps at most for each agent, each in its own real browser. Every step comes with a screenshot and what the agent was thinking at the time.
20agents at once, each acting as a different one of your users. The browser also records every error, failed request and request slower than 3 seconds on your site, on the step it happened. Agents find problems; they do not forecast how many people will convert.
$0for your first test, with a free account (Google sign-in, no card). It includes 50 credits, enough for 10 agents. After that an agent uses 5 credits, and packs start at $9 for 120 credits.
See a sample report

Questions

Do the agents use real email addresses?

They use addresses on a Mimiq domain with a working inbox, so codes and magic links reach them. Nothing is sent to real people.

Will my user list fill with test accounts?

Each agent that signs up creates one account, like a person would. Use a development or preview instance, or clean up afterwards.

Keep reading

Let the agents find what breaks first.

Your first test is free: sign in with Google and it starts right away. Last checked 2026-10-22.

5 agents try to .