FastQA·Monitors·Status pages·Run pages
Write a check in one line, point it at any page, and watch it run. Try the playground →

QA does not end at deploy.

FastQA opens your page the way a visitor does, runs the checks you wrote in one line each, and tells you which one failed and exactly what it saw.

No card. Five monitors on the free plan.

checkout — every 5 minutes
status is 200 in {page}200 in 412 ms
title exists in {page}“Checkout — Acme”
all links where external == 200 in {page}18 of 18 answered
×
element("#pay") exists in {page} with mode=browsernot found — the page rendered without the pay button

What a check can look at, without you writing any code

The platform

Six things, and they all speak the same language

Everything below runs the same checks, written the same way. Learn the one line and you have learned the product.

Domains

The sites you watch and the pages under them. Register a page before anything watches it and it is still listed, holding zeros.

Open Domains →

Monitors

What runs, against which pages, and how often. On a schedule, on a webhook, on an event, or when somebody presses Run.

Open Monitors →

Status pages

What you publish. A page your customers can read, with the incidents your monitors actually recorded — and an email list that hears about them.

Open Status pages →

Run pages

A page with a button. Somebody who is not in your account presses it, and a real check runs against a real page, right then.

Open Run pages →

Tasks

Your checks, named and reusable. Write one, point it at any page, and run it from as many monitors as you like. Take others from the shelf.

Open Tasks →

Playground

Type a check and watch it resolve as you go. It never fetches anything until you ask it to, so it is safe on every keystroke.

Open the playground →

The language

One line is a check. You can read it back a year later.

No YAML, no clicking through a wizard to describe a condition. Write what must be true, and FastQA tells you whether it was. One of them is a number: response time, as a check.

  1. 1
    Write it. A check names what it looks at and what it expects. {page} is where the page goes.
  2. 2
    Point it somewhere. The same check runs against one page or every page under a domain.
  3. 3
    Read the answer. Pass or fail — and for a fail, what it wanted and what it got.
# is the page there, and does it say what it should?
status is 200 in {page};
text contains "Add to basket" in {page};

# render it in a browser before looking
element("#pay") exists in {page} with mode=browser;

# follow every link and check each one answers
all links where external == 200 in {page};

Who it is for

The people who find out first when a page breaks

Engineering

Put the checks in the same place as the deploy. A monitor can be triggered by a webhook, so the thing that ships can be the thing that verifies.

QA

The checks you would run by hand, running by themselves on a schedule — against production, not a staging copy that drifted.

Ecommerce

Checkout, search, the basket. The paths that make money are the ones worth a check that opens them like a customer would.

Agencies

One team per client, each with its own domains, monitors and plan. Switch between them without signing out.

Support

A status page you can point at, with incidents that came from real checks rather than somebody remembering to update it.

Everyone else

A run page: a link, a button, and a real answer — for the people who need to know without needing an account.

Pricing

Start free. Pay when you outgrow it.

The free plan is a real plan, not a trial that expires. It runs the same checks the paid one does.

Free

€0 / month

Not a trial. It does not expire.

  • 5 monitors
  • Every kind of check — HTTP, text, DOM and links
  • Status pages and run pages
  • Teams, with roles — as many people as you like
  • 30 days of history
Start free

Pro

€6 / month

Per team, not per person. Excl. VAT — a business with a VAT number pays no more.

  • 100 monitors
  • History kept, not aged out at 30 days
  • The playground, and trying a check live
  • Everything the free plan has
Start free, upgrade later

Questions

The things people ask first

How is this different from uptime monitoring?

It is a different job. Uptime monitoring asks whether the server answered. FastQA is QA: it opens the page and verifies what you said must be true of it — the status, the words, the elements, the links. Reachability is one thing a check can assert along the way, not the product.

Do I have to write code?

No. A check is one line of plain language: what to look at, and what must be true of it. The playground shows you whether the line resolves as you type, before it fetches anything.

Can it check things that only exist after JavaScript runs?

Yes — add with mode=browser and the page is rendered in a real browser before the check looks at it.

What happens when a check fails?

You get the verdict and the evidence: what the check wanted, what it got, and which page it was looking at. A failure you cannot reproduce is a failure you cannot fix.

Can other people see the results?

A status page publishes what your monitors recorded, and can email the people who subscribe to it. A run page gives somebody a button instead, so they can ask for a fresh answer themselves.

Find out before your customers do

Five monitors, free, no card. Write your first check in about a minute.