Production smoke testing checklist for small SaaS teams

After deploying a SaaS release, open the public site and verify a small set of customer tasks with explicit outcomes. Start with browsing and navigation. Keep actions that create accounts, send messages or move money in an environment designed for those checks. Record what passed, what failed and what you could not check.

That is the purpose of production smoke testing: collect enough focused evidence to notice an important release problem while you can still respond. The checklist below gives a small team a repeatable starting point without pretending that a handful of browser checks proves the entire application works.

Confirm the deployment you are checking

Record the public origin, release identifier, deployment time and person running the checks. If the application exposes a build identifier, compare it with the intended release. Otherwise, keep the deployment record alongside your observations and avoid claiming that a visible page proves which version served it.

Use the actual customer URL, including the expected hostname and HTTPS. A successful preview deployment does not establish that the production hostname routes correctly. Start with a fresh browser session for public checks, then record any separate authenticated session you use.

A health endpoint is useful context, but give it its own result. HTTP 200 reports success for the request; it does not describe whether a later browser interaction fulfills a customer task. MDN explains the meaning of 200 OK.

Write down the scope before starting: for example, “Public desktop Chromium checks for release R; authenticated editing and billing tested separately in staging.” That sentence makes the limits of a green checklist understandable.

Use a checklist with visible pass conditions

The following worksheet is a hypothetical example for a document-template SaaS called DraftDesk. Its seeded public template, “Weekly review,” is controlled fixture data. Replace the routes, labels and outcomes with your own product's behavior. These are proposed checks, not reported test results.

Starting state	Action	Visible pass condition	Data impact	Evidence and reviewer
Fresh session on public home page	Open the production URL	Main product heading and primary navigation are visible	Browsing only	URL and screenshot; releasing developer
Home page	Follow Pricing	Expected pricing route and plan descriptions appear	Browsing only	Final URL and screenshot; releasing developer
Public template library	Search for seeded “Weekly review”	Expected template appears and its detail page matches the selection	Read-only search, assuming this is the product's search behavior	Query, result and detail screenshot; feature owner
Home page	Follow Create account	Signup form displays the expected fields	Stop before submission	Final URL and form screenshot; account-flow owner
Public help page	Follow a key help link, then navigate back	Intended article loads and return navigation remains usable	Browsing only	Article URL and failed step if any; releasing developer

Even in a solo business, fill in the reviewer column. It tells you who must make a decision before the release check is considered finished. If one person fills every role, use their name.

For each row, record pass, fail, blocked or not run. “Blocked: fixture missing” gives useful information. Leaving the cell empty makes it unclear whether someone forgot the check or tried it unsuccessfully.

Do not let the account-entry row imply that signup works end to end. Opening a form verifies entry into the journey. Creating an account, receiving verification and reaching the product require additional controlled checks.

Separate browsing from actions with consequences

Review each action before running it against production. A button labeled Preview might create a document. A form that looks harmless might notify a sales inbox. Decide based on the application's behavior, including downstream effects.

For the initial live checklist, prefer public pages and known read-only interactions. Use fixture content your team controls so a missing customer record does not make the result ambiguous. Keep requests modest and avoid testing expensive exports or bulk operations as casual browsing checks.

Put account creation, invitations, password recovery and billing in a separate worksheet with an explicit environment, test identity and cleanup owner. Configure email delivery to a controlled test sink rather than a real recipient. Use isolated test accounts and prevent integrations from forwarding test events to customers.

For Stripe integrations, use a sandbox with the corresponding test credentials and payment values. Stripe documents this environment as a way to simulate payments without moving real money. A test card number is not a safety boundary if the rest of the integration is configured incorrectly. Stripe's testing documentation describes the supported setup.

A staging payment pass should be recorded as staging evidence. It does not establish that the production payment configuration works. Review production configuration separately, and follow your payment provider's testing rules rather than making live charges as a routine smoke check.

Make each failure actionable

Capture the release, time, starting URL, final URL, action, expected outcome and observed outcome. Add a screenshot at the failure point. Where available, retain the relevant response or console error, with private values removed before sharing.

A useful note reads: “Release R, fresh public session, clicked Pricing from the home page; expected pricing plans, observed the not-found page at /plans-old.” “Pricing broken” leaves the next person to reconstruct the experiment.

Consider that hypothetical navigation failure. Opening /pricing directly could pass while following the home-page link still fails. Your check should preserve the customer's starting point and action so it catches the broken transition. After a fix, repeat that transition; visiting only the destination would verify a different behavior.

Store evidence with the result rather than relying on a chat message someone may lose. Screenshots should use public or controlled fixture data. Remove account details, access tokens and unrelated private information from anything shared outside the team.

Decide what happens when a row is red

Assign the response according to the failed task. If a release breaks the main path into the product, pause further rollout and assess rollback or a targeted fix. If a help link fails, record the impact and give the repair an owner. The checklist supplies evidence; the team still decides what the impact warrants.

Preserve the initial failure before rerunning. A later pass is another observation, and it does not explain the earlier failure by itself. If access or data prevents a check, keep it blocked until the missing prerequisite is resolved.

When all selected checks pass, report the scope alongside the result. A public smoke pass does not cover private permissions, every browser, data migrations, security properties or the complete regression suite.

Automate the checks that have settled

Once the steps and fixture data are stable, encode the same visible outcomes in browser scripts. Playwright's web assertions can retry until an expected condition is met or the assertion times out, which helps express waiting for an outcome instead of guessing a delay. Playwright's assertion guide documents the available checks.

Keep a human responsible for reviewing failures and updating expectations when product behavior intentionally changes. Automation is most useful when a failed check has a clear meaning and someone knows what to do next.

ReplaceQA is in closed beta. It explores public URLs, generates Playwright scripts and retains validation steps, screenshots and video, with partial or blocked coverage kept visible. You can request closed-beta access to explore the public journeys in your own release checklist.