Choose critical workflows and authorised test accounts. Decide which tests can run against production without creating real charges, customer messages or unwanted data.

1. Check the public HTTPS endpoint, release identifier and a representative asset. Verify the intended response content, not only a 200 status code.

2. Exercise a controlled authenticated workflow and a harmless database read or write where appropriate. Keep test data clearly identifiable and remove it through the application’s supported process.

3. Check a required background job or external integration through a test mode or safe status operation. Avoid a real payment or mass email as an automatic health probe.

4. Review private application errors and restart behavior. Compare the release with the known baseline rather than expecting logs to be completely empty.

5. Define the failure decision in advance: pause activation, recover compatible code or investigate a specific dependency.

Choose a public, read-only endpoint with a stable marker controlled by your application. This Python smoke check expects JSON from an example release endpoint. Replace the URL and expected release with values your application deliberately exposes without confidential configuration.

import json
from urllib.request import urlopen

with urlopen('https://example.com/health/release', timeout=10) as response:
    assert response.status == 200
    assert response.headers.get_content_type() == 'application/json'
    payload = json.load(response)

assert payload.get('release') == 'example-2026-10-05.1'
assert payload.get('status') == 'ok'

A 200 response containing a maintenance page will now fail instead of falsely approving the deployment. Add a separate approved login or draft workflow when the application’s critical feature is not represented by this endpoint. Keep genuine purchases and customer emails out of routine smoke checks.

Expected result: The intended release passes, while a stale deployment or HTML fallback fails clearly and pauses activation until investigated.

Confirm the checks detect a deliberately broken staging configuration and remain successful on a healthy release. Remove checks that merely repeat implementation details without finding a realistic deployment problem.

If a test fails only on production, compare credentials, proxy behavior, data shape and resource limits. Do not suppress the check until its failure is understood.

• Setting up a staging branch deployment workflow
• Choosing a health check that reflects user-visible failure
• Rolling back application files without losing new user data
• Building a deployment artifact in CI

• GitHub deployment environments
• Django deployment checklist

• Express health checks and graceful shutdown