Preview URLs
→Your critical tests, pointed at the pull request's preview URL.
Post-deploy monitoring
Find out if a deploy broke something before your users do.
Smoketest monitors your critical tests in a real browser after every deploy. It tells you the moment login, checkout, or onboarding stops working, and signals recovery once the test is healthy again.
Works with GitHub Actions, PR checks, and deployment webhooks. Your first check in about two minutes.
smoketest.sh/dashboard
acme-web⌄
Testing
Overview
Board
Runs
Analytics
Test Library
Tests
Shared Steps
Tags
Project
Environments
Notifications
Automations
Board
Tickets currently moving through QA
All activeSources
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
Every deploy is a roll of the dice.
Deploy and pray
You merge, ship, and refresh the app hoping nothing in the happy path broke.
The 200 OK lie
Your uptime monitor stays green while checkout quietly returns a 500.
Found by customers
A broken release reaches users before any of your tools notice.
Which deploy broke it?
Something regressed days ago and now you're bisecting releases by hand.
What a test looks like
You write sentences. They run on every deploy.
you write
Open the deployed app. 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
Runs after every deploy via GitHub Actions, PR and push checks, or deployment webhooks
Opens the live or preview URL in a real browser
Performs each step like a user, then verifies the result
Returns a pass or fail result tied to the release
Alerts Slack, Discord, or email the moment it breaks, and again when the test recovers
Use cases
Covered on every release.
Checkout
→User adds an item, checks out with the test card, and sees the confirmation.
Auth
→User logs in with email and password and lands on the dashboard.
Staging gate
→Your money-path tests, run against the staging deploy first.
The 200 OK lie
Your uptime monitor says green. Did the user get through?
After a deploy
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
Login redirect loops after a deploy
Misses it
Fails the run and shows where it looped
A form submits but saves nothing
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 deploy breaks something
Know which deploy broke it, and exactly where.
Every failed check is tied to the release that caused it, with a recording, a transcript, and the failing step.
deploy-482 · checkout.webm
00:00↑ 00:10 · checkout00:11
step log
Deploy webhook received · build #482
Opened the live deploy URL
Logged in with the test account
Added item · opened checkout
Expected confirmation · got 500 error
Session recording
Screenshot at failure
Step-by-step transcript
Downloadable Playwright trace
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 every deploy.
Run your critical tests on each release without counting seats or wiring up a test harness. 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 post-deploy monitoring
Post-deploy monitoring runs your critical user tests right after a release to confirm real users can still finish them. Instead of waiting for a bug report, you verify sign-up, login, and checkout against the deployed app and get a pass or fail result within minutes of shipping. When a test that failed passes again, you get a recovery signal too.
Connect Smoketest to your pipeline. It runs your written tests from GitHub Actions, on GitHub pull-request and push checks, on deployment webhooks from hosts like Vercel and Netlify, from Claude Code or Cursor over MCP, or from the public API and CLI. Each deploy triggers the tests you choose and reports back automatically.
Yes. Install the GitHub App and map a repository to your project. Smoketest adds a check to each pull request, runs the tests you've tagged, and posts an aggregate status with links to every run, so you see green before you merge.
Yes. Point your host's deployment webhook at Smoketest and it runs your tests when a new deploy goes live. You can target the production URL or the preview URL for that specific deploy.
Yes. Any run can override the start URL, so the same saved test can run against a pull-request preview, a staging deploy, or production without being rewritten.
An uptime monitor checks that a page responds. It can return 200 OK while checkout is broken, a form silently fails to save, or login redirects into a loop. Post-deploy testing runs the actual user journey end to end, so it catches failures a status check can't see.
You get a clear fail result with the failure reason, a screenshot at the failing step, the full session recording, a step-by-step transcript, and a downloadable Playwright trace. Notifications can go to email, Slack, or Discord so the right people hear about it first. When a later run of that test passes again, Smoketest sends a recovery alert so you know it is healthy.
Runs happen against the deployed app, so they don't block the build. You decide whether a pull-request check waits for the result or whether deploy-triggered runs report asynchronously after the release is live.
Yes. The public API and CLI let you start runs, watch them live, and read results from any pipeline or script, so post-deploy testing fits whatever CI you already use.
Start with the journeys that make you money or block users if they break: login, sign-up, checkout, billing, and core onboarding. Tag them as a group and run the whole group on each deploy.
Stop deploying and hoping.
Wire your critical tests into every deploy. Get a result in minutes, with the recording when something breaks.
Read the docs