Scheduled user test monitoring

Know your critical tests still work, every hour, every day.

Smoketest monitors sign-up, login, and checkout in a real browser on the schedule you set. It alerts you the moment one breaks, and signals recovery when the test is healthy again.

Hourly, daily, or weekly. Your first check in about two minutes.

smoketest.sh/dashboard
Board
Tickets currently moving through QA
Development1
Jira · APP-917
Invite member from workspace settings
App QANot tested
Testing2
Linear · WEB-284
Apply annual discount at checkout
Checkout QARunning
Linear · AUTH-126
Recover account with magic link
Authentication QANeeds attention
Passed1
Jira · BILL-442
Show updated invoice after seat change
Billing QAPassed
The problem

Things break when no one is deploying.

Breaks between deploys

Nothing shipped, but a token expired and login broke at 2am anyway.

Third parties fail quietly

Your email or payment provider has an outage and a test silently dies.

The 200 OK lie

Your uptime monitor stays green while checkout returns a 500.

Found by customers

You hear the money path is down from a refund request, not a tool.

What a test looks like

You write sentences. They run on a schedule.

you write
Log in with the test account.
Add an item and check out with the test card.
Confirm the order confirmation appears.
smoketest does the rest
Re-runs on the schedule you set: hourly, daily, or weekly
Opens your live app in a real browser, timezone-aware
Performs each step like a user, then verifies the result
Returns a pass or fail result every run
Alerts Slack, Discord, or email the moment it breaks, and again when it recovers
Use cases

Watch the tests that can't break.

Hourly checkout

User adds an item, checks out with the test card, and sees the confirmation.

Billing

User upgrades to Pro and the workspace shows Pro features enabled.

Magic link

User requests a magic link, opens it, and lands authenticated.

Login, off-hours

User logs in with email and password and lands on the dashboard.
The 200 OK lie

Your uptime monitor says green. Is the money path working?

Around the clock
Uptime monitor
Smoketest
Home page returns 200
Catches it
Catches it, then keeps going
Checkout actually charges the card
Misses it
Runs the full purchase in a real browser
Magic-link login still works
Misses it
Opens the real link and lands authenticated
An upgrade silently stops working
Misses it
Verifies the result, not just the request
What you get on a failure
A pinged status
Recording, transcript, result, failing step
When a scheduled run fails

You hear about it first, with the proof attached.

A failed run alerts the channel you choose and saves the recording, the transcript, and the exact step that broke. When a later run passes, you get a recovery alert on the same channel.

daily-0900 · checkout.webm
00:00↑ 00:09 · checkout00:11
step log
Scheduled run started · daily 09:00
Logged in with the test account
Added item · opened checkout
Submitted payment with the test card
Expected confirmation · stuck on spinner
Session recording
Screenshot at failure
Step-by-step transcript
Slack, Discord & email alerts
How it works

Jira or Linear starts the Test.

Keep the workflow where QA already works. Smoketest adds execution, evidence, and routing without becoming another board.

workspace · connections
Lhealthy
Linear
Acme workspace
Jhealthy
Jira
acme.atlassian.net
01

Connect Jira or Linear

A workspace owner authorizes Jira or Linear once. Smoketest keeps Connection identity, permissions, token health, and webhook health visible.

new test source
Listen to
Checkout board · QA
Passed
Ready to release
Failed
Development
Run at
staging.acme.com · Desktop
Permissions and direct transitions validated
02

Define the QA handoff

Choose the team or board, exact QA status, direct Passed and Development statuses, then set the URL, Environment, device, and access settings.

test request · attempt 1
WEB-284 enters QA
Ticket + linked PR frozen
Generated Test created
Browser Run in progress
03

Let the ticket start testing

When a ticket enters QA, Smoketest freezes current context, enriches it from an eligible ticket-linked pull request, generates one Test, and runs it automatically.

result · synchronized
PASSEDWEB-2841m 42s
Attempt comment updated with evidence
Authenticated recording and transcript linked
QAReady to release
04

Return the Result safely

Smoketest posts evidence to one evolving Attempt comment. Passed moves forward, Failed returns to Development, and No Result stays in QA. Newer human changes always win.

Pricing

One plan covers you around the clock.

Schedule the tests that matter most and pay only for the runs you use. Start with the money path, add more as you trust it.

14-day free trial · 50 credits · no card
One plan: $39/mo, or $32/mo billed annually
300 credits/month · 1 credit = one run up to 10 min
FAQ

Questions about scheduled monitoring

A smoke test is a quick check of the most important paths through your app, the journeys that, if broken, mean the product is effectively down. For a web app that usually means sign-up, login, checkout, and core onboarding. If those pass, the build is healthy enough to trust.

A scheduled smoke test re-runs those critical tests automatically on a set cadence, hourly, daily, or weekly, instead of only when you deploy. It is continuous monitoring for the journeys users actually take, and it catches breakage that appears between releases, like an expired token, a third-party outage, or a config change, before users report it.

Run the tests that make you money as often as they change or as often as a quiet failure would hurt. Many teams run checkout and login hourly or a few times a day, and broader journeys daily. You can set a different cadence per test.

Smoketest uses timezone-aware presets: run a test every few hours, at chosen times each day, or on a specific day each week. Pick the cadence per test from your project settings, no cron syntax to write.

Post-deploy testing runs when you ship; scheduled smoke tests run on the clock. Together they cover both kinds of breakage, the change you just made, and the failure that creeps in between deploys. Most teams use both on the same tests.

Yes. Send notifications to email, Slack, or Discord, and filter them per project: every run, or failures and recovery only so you hear when a test breaks and when it comes back, without a ping on every green run. You hear about a broken test before your customers do.

Yes. Store a test account and card as environment variables and the agent logs in and completes the purchase on each scheduled run. Secrets stay out of your test text and out of the logs.

No. Uptime checks confirm a page responds. A scheduled smoke test drives the real user journey in a real browser, clicking, typing, and verifying the outcome, so it catches a broken checkout that still returns 200 OK.

Yes. Each run uses one credit for up to ten minutes of run time. The plan includes 300 credits a month, and you can add more if your cadence needs them.

Write a test in a sentence, run it once to confirm it does what you mean, then pick a schedule from the test's settings. From then on it runs on its own and alerts you if it breaks.

Stop finding out from your customers.

Put your critical tests on a schedule. Get an alert and the recording the moment one stops working.

Read the docs