A smoke test is a short, shallow set of checks run immediately after a build or deploy to answer one question: is this obviously broken? It does not try to verify every feature or edge case. It checks that the application starts, the homepage loads, login works, and the two or three flows that would be an embarrassing outage if they failed. The term comes from hardware testing — power on the device and check for smoke before running any real diagnostics.
What changed in 2026
- Smoke tests became a standard gate in deploy pipelines, running automatically against a freshly deployed environment before traffic is fully shifted over, rather than as a manual post-release checklist.
- Synthetic monitoring and smoke testing converged — the same lightweight checks that gate a deploy now often run on a schedule in production as a continuous health signal.
- Smoke suites got explicit time budgets in CI config, commonly under five minutes, after teams noticed smoke suites quietly growing into slow regression suites over time.
- Smoke tests after infrastructure changes became routine, including after a database migration runs, to catch schema drift before real users do.
What belongs in a smoke test
| Category |
Example check |
Why it is in scope |
| Startup |
App boots, health endpoint returns 200 |
Nothing else matters if this fails |
| Critical path |
Login, checkout, or core action completes |
Highest-visibility failure if broken |
| Key integration |
Database connection, primary API reachable |
Common single point of failure |
| Static assets |
Homepage renders, no blank screen |
Cheap check for build or CDN issues |
Everything else — edge cases, error states, less-used features — belongs in the regression suite, not the smoke test.
How a smoke test differs from other tests
A smoke test is intentionally shallow and fast. A regression test suite is deep and thorough, designed to catch old bugs from reappearing across the whole feature surface. A sanity test sits in between — narrow but deeper than smoke, usually run manually after a specific fix to confirm that fix and its immediate surroundings work. The three are not competitors; they run at different points and depths.
Writing a smoke test that stays useful
- Time-box it explicitly. If the suite creeps past five minutes, split it — move anything non-critical into the regression suite.
- Run it against the actual deployed environment, not a local dev server, so it catches real configuration and infrastructure issues.
- Fail loud and fail the deploy. A smoke test that only warns instead of blocking gets ignored the first time someone is in a hurry.
- Keep the list of checks short enough to read in one sitting. If you cannot list what is covered from memory, it has grown too large.
Common mistakes
Letting the smoke suite absorb every "just in case" check. Each addition feels reasonable in isolation; the sum becomes a slow, redundant regression suite with a misleading name.
Running smoke tests only against staging, never production after a real deploy. Configuration drift between environments is exactly what a post-deploy smoke test is meant to catch.
Treating a passing smoke test as proof the release is safe. It only proves the release is not obviously broken — deeper testing still matters.
FAQ
How is a smoke test different from a regression test?
A smoke test is fast and shallow, checking that the build is not fundamentally broken. A regression test suite is deep and thorough, checking that previously working features still work across many scenarios.
How long should a smoke test suite take?
Most teams target well under five minutes. If it grows past that, split out anything that is not truly critical into a separate, deeper suite.
Should smoke tests run in production?
Yes, commonly right after a deploy and often on a recurring schedule afterward as a lightweight health check, sometimes shared with synthetic monitoring.
Can smoke tests be manual?
Yes, especially on small teams, but automating even a handful of checks removes the temptation to skip them under deadline pressure, which is when they matter most.
Where to go next