Molar.
Get started

Know which check failed before you ship.

Guard runs your sign-up, checkout and account checks on every pull request and on a schedule, and shows the step that failed. Each check is a Playwright test, so no AI agent decides pass or fail.

Get started free See an example check

Guard is in beta. Install the GitHub App or add the GitHub Action to start.

Run the checks your release depends on.

Pick when the check runs, see the tests it includes, and open the check that decides the result. This interactive example uses sample data.

Release checkscheckout scenario
Required check · PR #184

checkout

FAILED
preview · pr-184run_7f2c · 4 assertions
03Assertion failed12.4s

Payment succeeded, account access missing

Payment record pi_sample_184 is complete. The signed-in customer still has no pro entitlement after the callback.

Open Trace example

Sample state: the payment callback arrived, but the account never got Pro.

See why a change
selects a test.

A billing change should bring checkout into focus. Guard picks the scenarios connected to the files a pull request changed, plus any scenario file it edits. Test selection is in beta, so check the reason before trusting the scope.

Pull request → test selectionInteractive example · 3 configured scenarios
Changed in this pull requestsrc/billing/access.ts
Billing access → checkout
  • checkoutSelected
  • signin-and-dashboardNot selected
  • invite-memberNot selected

1 of 3 scenarios selected

The dependency map connects this file to checkout. Sign-in and invitations have no matching dependency in this example.

Selection only · no execution result

Skip a rerun when nothing changed.

If nothing a test depends on has changed since an earlier commit where it passed, Guard can reuse that pass and label it “cached.” It compares the scenario, its source files, the runner version, dependency files and the clones it uses. This works for pull requests checked through the GitHub App.

A cached check is not a fresh browser run. Remote services and deployed environments can change independently of a commit.

Make missing coverage visible.

A large change that matches no mapped dependency runs every scenario. A small unmapped change can select nothing. Review the selection and update the map or choose the relevant tests explicitly.

Selection, a cached result and a newly passed assertion answer different questions. Keep all three visible to the reviewer.

Add a check to each
stage of your release.

Set the URL, test account, scenario and merge rule once. Then read the result for each pull request and deployment.

01

Prepare

Install and authenticate the CLI. Connect the repository and preview environment. Give the scenario a dedicated test account and only the service endpoints it needs.

02

Gate

Run the configured scenario in CI and mark the chosen GitHub job as required in repository settings. Guard reports the result; your branch protection policy decides whether a merge is allowed.

03

Observe

After deployment, schedule an authorized login, checkout, or account check against the selected URL. Use dedicated test accounts so scheduled checks never touch real customer data.

04

Investigate

Open the failed assertion, browser steps, screenshots, and available Trace reference. Mender can prepare a repair preview for review; a human still decides what enters the repository.

A scenario file and one step in CI.

A scenario is a .molar.md file in .molar/scenarios/: a short header naming the clones it uses, then plain-English steps and checks. Molar compiles it into a Playwright test, so no AI agent decides pass or fail in CI. Register the scenario in Guard, then add the GitHub Action with its scenario ID. Keep your API key in your CI secret store.

Read Guard setup docs
Scenario and CI step
# .molar/scenarios/checkout.molar.md
---
slug: checkout
clones:
  - { kind: stripe }
  - { kind: email }
---
1. Navigate to /pricing
2. Click "Subscribe Pro"
3. Fill the card with 4242424242424242
4. Wait for webhook stripe.checkout.session.completed
5. Assert Email Clone outbox contains 1 email
6. Assert text "Welcome to Pro" is visible

# .github/workflows/guard.yml (step)
- uses: pratikranaa/guard-action@v1
  with:
    api-key: ${{ secrets.MOLAR_API_KEY }}
    scenario-id: ${{ vars.CHECKOUT_SCENARIO_ID }}
    base-url: ${{ steps.deploy.outputs.url }}
    mode: required
molar / checkoutExample failed job · account access assertionInspect failure

Follow the same check
after deployment.

A checkout that passed at midnight can fail by morning. Open each scheduled run’s target, check and captured result to see what changed. Each scheduled run counts toward your 25 hosted runs a day.

Scheduled checks · sample historyEvery 6 hours · one target
Select a scheduled run to inspect its result. All times are UTC.
Scenario00:0006:0012:00
checkout
signin-and-dashboard
invite-member
06:00 UTC · northstar.test

checkout

Failed
Expected
Pro access after test payment
Observed
Payment completed. Account still shows Free.

Inspect the callback and account-access assertion in the failed run.

Define what the schedule may touch.

Choose the target URL, scenario, cadence, available region, dedicated credentials and alert destination. Validate the production safety setup before creating a schedule, then inspect its first completed run.

Clones isolate supported vendor calls only when your app uses their endpoints. Your production database, analytics and other integrations still need explicit test-data boundaries.

Plan a production check

Read results from your terminal.

Molar CLI · current status and recent failures
molar guard status --pattern "checkout*" --json
molar guard failures --pattern "checkout*" --limit 10 --json

Use the configured Molar CLI after sign-in with workspace access. These commands read existing checks; they do not create a schedule or start a browser.

A failed checkout.
A fix you can review.

Mender can use a failing run and repository context to prepare a repair proposal. Review the change, its regression test and fresh validation before approving it. Mender is in preview.

Payment completed.
Pro access did not.

Keep the original assertion and callback details. The payment record alone does not prove that the customer received access.

Inspect the Trace example

Check the code that grants access.

Review how the callback updates the account. Keep the proposed diff within allowed paths and check it against the captured failure.

Prove the customer can use the plan.

Run from prepared test state. Check both the purchased plan and the action it should unlock. Keep the new result separate from the original failure.

Receiving payment is only half the check.

Playwright · example assertion excerpt
await expect(page.getByTestId('account-plan'))
  .toHaveText('Pro');
await expect(page.getByRole('button', {
  name: 'New shared project'
})).toBeEnabled();

Illustrative assertions after a test payment and return to the account page. Adapt the locators, fixtures and setup to your app. This excerpt is not an executed repair.

Before approval
  • Review the source change and regression test.
  • Check that relevant tests ran against the proposed fix.
  • Keep Mender’s path limits and permissions in place.
  • Apply your repository’s review and merge policy.
Explore the Mender review process
CartographerExplore your app and develop the scenarios to check.ClonesPrepare supported test services and restore their state.TraceInspect the browser steps and captured service events.

Compare with the tools you already use.

Playwright provides browser tests; tools such as Checkly also run checks in CI and on schedules. Evaluate Guard’s scenario selection, test-service setup and failure investigation on a flow from your own app.

Molar and Playwright Compare with Checkly

Frequently asked questions

Have a specific workflow in mind?
Talk to us

What does Guard run?

Guard runs configured scenarios in CI, after deployment, or on a schedule. A scenario can follow a browser journey and check the resulting application state; supported Clones can provide isolated payment, email, identity, SMS, or storage behavior where the workflow needs it.

What is a scenario?

A .molar.md file in .molar/scenarios/ with a short YAML header (its name and the clones it uses) and plain-English steps and checks. Molar compiles it into a Playwright test.

Does an AI agent decide pass or fail in CI?

No. Guard runs Playwright tests: ones compiled from your scenarios, or your existing Playwright specs through the GitHub App or the CLI. AI only helps after a failure: Guard can suggest a fix for a broken locator, and Mender, when you turn it on, can propose a code fix.

How does Guard handle flaky runs?

A failing check fails the run. Guard doesn’t retry automatically or mark a later pass as flaky yet. If Mender is on, it reruns a failure three times and reports a flake instead of a bug when most reruns pass.

How does Guard choose tests?

Where dependency mapping is configured, Guard selects scenarios connected to changed files and directly edited .molar.md scenarios. Broad selections and large unmapped changes can trigger full-suite fallback. A small unmapped change can select nothing, so inspect the reason and choose an explicit test set where coverage is missing.

What do I need before adding the CI job?

Install and authenticate the CLI, connect the repository and target environment, define the scenario and its assertions, and prepare dedicated test credentials or Clones. Keep secrets in your CI secret store and make the selected GitHub job required in repository settings.

Can Guard check a preview or production URL?

Yes, for an authorized workflow. Use the preview URL for a release check and a scheduled, permission-scoped target for production monitoring. Use dedicated test accounts for production checks so they never touch real customer data.

What does a failed run show?

The result keeps the scenario and run identity with the failed assertion and available browser steps, screenshots, artifacts, and Trace reference. Check whether the failure is an application assertion, missing access, or environment setup issue before rerunning.

Does Guard replace Playwright?

No. Guard can complement an existing Playwright suite. Evaluate the configured scenario, environment setup, evidence, and maintenance work on a flow that matters to your team.

Does a cached result mean the browser ran again?

No. A cached result reuses an earlier pass because nothing the test depends on changed. It doesn’t run the browser again or prove that a remote environment stayed the same, so Guard labels it “cached.”

Does a change with no mapped dependency run every scenario?

Only a large one. Guard runs every scenario when more than 50 are affected, or when an unmapped change touches more than 10 files or 500 lines. A smaller unmapped change can select nothing, so review coverage and run the relevant tests yourself.

Can I monitor from multiple regions?

Not yet. During the beta, scheduled runs come from Molar’s hosted browser in Azure Central India. This page’s history illustrates a single target; it is not a live monitoring report.

Do Clones prevent all production side effects?

Clones isolate supported vendor operations when your app is configured to call them. They do not automatically intercept every outgoing request or isolate your production database. Use dedicated test identities, scoped data, configured endpoints and a validated safety setup.

Will Mender merge or deploy a fix?

No. Mender is a preview workflow that prepares a proposed repair for review. A human reviews the diff and repository policy remains in control of approval, merge, and deployment.

Choose the check your next release needs.

Create a free workspace, add your app’s URL and a test account, and describe the first task to check.

Get started free Talk to us

Free during the beta. No card.