What smoke checks would you run after deploying a .NET backend or full-stack release?

In production smoke checks are one promotion gate, not the whole release verdict. They run against a warmed staging slot or canary and again after traffic changes, while dashboards watch error rate, latency, saturation, dependency failures, queue age, and a business success signal. The release policy defines which smoke failure blocks promotion, when an automatic retry is acceptable, and who decides pause, rollback, flag disablement, or forward repair. Checks tolerate rolling-version overlap and do not rely on a database schema that only the newest instance understands. Synthetic identities have least privilege, test records are clearly marked and bounded, external providers use sandbox or non-billable operations, and cleanup is idempotent. I monitor smoke-test reliability itself so a flaky probe cannot normalize bypassing the gate. Failure drills prove the checks catch missing secrets, wrong routes, identity configuration, migration incompatibility, and unavailable dependencies. This gives the team quick evidence that a release is usable while live telemetry catches load, concurrency, and cohort failures a tiny synthetic path cannot reproduce.