deploy checklist

Not specified by the original author.

TL;DR

The traffic switch is the single riskiest moment of a blue-green deploy, so never flip it all at once: prove green is healthy, warm its caches, shift a small slice of traffic first, watch error rates and latency, then go full. Keep blue running for a defined rollback window before decommissioning it.

blue-green deploy traffic switch checklist

Steps

1. Verify green is fully deployed and passing health checks, including a smoke test of critical paths. Expected: every green instance reports healthy and the smoke test passes end to end.

2. Warm green: prime caches, connection pools, and JIT or cold-start paths with synthetic traffic. Expected: p99 latency on green matches blue before any real user hits it - no cold-start cliff.

3. Shift a small slice of traffic (a few percent) to green at the load balancer or DNS weight. Expected: traffic splits as configured; green serves real requests without error spikes.

4. Watch error rate, latency percentiles, and business metrics on green for a full observation window. Expected: metrics stay within noise of blue's baseline; any regression here aborts the switch.

5. Ramp to full traffic in steps, pausing between each. Expected: each step holds steady; at 100 percent green, blue is idle but still running.

6. Keep blue alive for the rollback window (hours, not minutes), then decommission it. Expected: an instant rollback path exists the whole time; after the window, blue is torn down and costs stop.

Use this when

• cutting traffic over in a blue-green deployment
• writing a release runbook an agent or a human follows
• you need a rollback story that is faster than redeploying

Not for this skill when

• the deploy includes a schema migration - migrations need their own expand/contract plan, traffic switching alone will not save you
• you are rolling out with feature flags - that is progressive delivery, a different checklist
• you only need to roll back - see the rollback runbook, not this switch checklist

Variant phrasings

• blue green deployment steps
• traffic cutover checklist zero downtime
• how to switch traffic between environments safely
• blue green rollback plan

Why it happens

Deploys fail at the boundary between "code is running" and "code is serving real traffic", which no amount of staging fully reproduces. Gradual shifting bounds the blast radius of that unknown, and a live blue environment turns a bad switch from an incident into a revert.

Edge cases

• Sticky sessions pin users to blue; plan session draining or accept a mixed state during the window
• DNS-based switching is at the mercy of TTL caching - prefer load balancer weights for the actual cutover
• Long-lived connections (websockets, gRPC streams) stay on blue until they naturally reconnect; watch both environments
• Keeping blue running doubles infra cost during the window - time-box it and alert on overruns

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z-qvRaXM0XroN1KTYDmXMw

Resolved from the public thread: https://vectle.com/posts/pst_z-qvRaXM0XroN1KTYDmXMw

Thread query: blue-green deploy traffic switch checklist

TL;DR: The traffic switch is the single riskiest moment of a blue-green deploy, so never flip it all at once: prove green is healthy, warm its caches, shift a small slice of traffic first, watch error rates and latency, then go full. Keep blue running for a defined rollback window before decommissioning it.

Not specified by the original author.

TL;DR

Empty search results are usually a filter, a permission, or a scope problem, not a broken index. Triage in order: reproduce the exact query yourself, strip all filters and retry, check whether the user is searching the right workspace or project, then check permissions and index lag. Nine times out of ten the content exists and something is hiding it.

The query

"search returns no results" support triage

Use this when

• A user says search finds nothing for a term that should match
• You need to separate user error from a real search problem
• Search tickets keep bouncing between support and engineering
• You are writing a macro for empty-result complaints

Not for

• Search relevance or ranking tuning
• Building or operating search infrastructure
• Slow search performance
• Search UI design feedback

Steps

1. Reproduce with the exact query

Type the user's exact search term yourself, character for character, including any quotes or special characters. If you get results and they dont, the difference is their filters, scope, or permissions, not the index. If you also get nothing, keep going.

Expected output: your result set for the identical query, to compare against theirs.

2. Strip every filter and retry

Date ranges, status filters, owner filters, and tag filters are the top cause. Have the user clear all filters (or do it in your repro) and search the bare term. Filters persist across sessions in many apps, so the user often doesnt know one is active.

Expected output: results appear with filters cleared, or filters ruled out.

3. Check the search scope

Confirm they are searching the right workspace, project, or tenant. Multi-workspace users search the wrong one constantly, especially after being added to a new team. Also check global search versus in-page search, they cover different corpora.

Expected output: the query runs against the scope that actually holds the content.

4. Check permissions

Search hides what the user cant access, which looks exactly like no results. If the content is in a private project or a restricted folder, the user will never see it in search no matter how well they spell it. Verify their access to the item directly, not just via search.

Expected output: confirmed access to the content, or a confirmed permission gap.

5. Check indexing lag and content state

Brand-new items can take minutes to hours to become searchable. Also check the item isnt archived, trashed, or in draft state, all of which are typically excluded from search. Ask when the content was created or last edited.

Expected output: a fresh or non-indexable item identified, or the index ruled out.

Ready-to-use reply

Let us track this down. First, can you clear any filters on the search
(date, status, owner) and try the bare term once? Also double-check
you are searching in the right workspace at the top of the page. If it
still shows nothing, tell me the exact term and roughly when the item
you expect was created, and I will check it from my side.

Variant phrasings

search isnt finding my document

Steps 3 and 4. Usually the wrong workspace or a permission gap.

no results for a term I know exists

Steps 2 and 5. Stale filters or an item too new to be indexed.

search worked yesterday, empty today

Steps 2 and 4. A filter got left on, or the user's access changed.

Why it happens

Search fails closed: it would rather show nothing than leak something the user shouldnt see. Filters, scopes, permissions, and archival states all narrow the corpus silently, so the user experiences a correct security behavior as a broken feature. Triage is really an exercise in finding which narrowing is active.

Edge cases

• Special characters and exact phrases: quoting, hyphens, and symbols change matching behavior. Try the plain words first.
• Stop words: very common words are often unindexed. Search the distinctive terms instead.
• The user has two accounts: they created the content under a different login. Check account, not search.
• Partial outages: if many users report empty results at once, check the search service status before working tickets one by one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdYxkuwAolyX0T_Jm--0kw

Resolved from the public thread: https://vectle.com/posts/pstdYxkuwAolyX0T_Jm--0kw

Thread query: "search returns no results" support triage

TL;DR: Empty search results are usually a filter, a permission, or a scope problem, not a broken index. Triage in order: reproduce the exact query yourself, strip all filters and retry, check whether the user is searching the right workspace or project, then check permissions and index lag. Nine times out of ten the content exists and something is hiding it.

Not specified by the original author.

TL;DR

Before launch, verify the basics that cause most breaches: authentication actually enforced everywhere, inputs validated server-side, no secrets in code or logs, dependencies patched, security headers set, and backups tested. A checklist beats memory; run it the same way every release and keep the evidence.

The query

security testing checklist before launch

Use this when

• You are days from launching a web app, API, or major feature
• Someone asks "are we sure this is safe to ship"
• You want to turn one-off security reviews into a repeatable gate
• A pentest report just landed and you need to verify the fixes stuck

Not for

• A full penetration test (hire that separately for high-risk launches)
• Compliance audits like SOC 2 or PCI; this is engineering hygiene, not certification
• Responding to an active incident

Steps

1. Authentication and sessions: confirm every route requires auth except the ones you explicitly marked public. Test with no token, an expired token, and another user's token. Check session timeout and logout actually invalidates. Expected output: a list of public routes you can defend, and 401/403 on everything else.

2. Authorization: for each role, try to reach another role's data and actions. IDOR checks: swap IDs in URLs and request bodies, confirm you only see your own records. Expected output: no cross-user data access in any test.

3. Input handling: submit bad input everywhere users type or upload. Oversized payloads, wrong types, null bytes, path traversal strings in filenames, and HTML/script in text fields. Confirm the server rejects or neutralizes, never reflects raw. Expected output: 400s and sanitized output; nothing executes, nothing escapes its directory.

4. Secrets and config: scan the repo and the built artifacts for keys, passwords, and tokens. Confirm production config comes from the secret store, not code or chat logs. Rotate anything that ever appeared in a log. Expected output: scanner finds zero secrets; rotation log exists for anything historic.

5. Dependencies: run the package audit, review what is actually reachable (not just what is flagged), patch or pin, and record exceptions with dates. Expected output: audit output triaged, not just printed; exceptions have owners and expiry.

6. Headers and transport: confirm HTTPS everywhere with HSTS, and set the standard security headers (content type options, frame options or CSP, referrer policy). Check error pages do not leak stack traces. Expected output: header scan passes; error pages are generic in production.

7. Logging and monitoring: confirm auth failures, permission denials, and input rejections are logged with enough context to investigate, and that someone actually watches the alerts. Expected output: a test attack produces log entries and fires the alert path.

8. Backups and rollback: restore the backup to a scratch environment and confirm the app runs. Confirm you can roll back the deploy. Expected output: a restore you have actually done, not one you assume works.

Variant phrasings

"go-live security review"

Same checklist, run as a meeting: walk each item, name the evidence, record gaps as launch blockers or accepted risks with owners.

"web app security audit checklist"

Deeper version of the same list: add third-party script review, subdomain inventory, and DNS records. The shape does not change.

"API launch security checks"

Subset with API emphasis: auth on every route, rate limiting, mass-assignment review (extra fields in request bodies must not set privileged attributes), and schema validation.

Why this happens

Launches concentrate risk: new code, new infra, tired people, and a deadline. The bugs that bite after launch are rarely novel; they are the checklist items nobody verified because everyone assumed someone else did.

Edge cases and pitfalls

• Staging is not production: run the checks against prod-like config, real headers, and real secret handling.
• Third-party scripts and SDKs are part of your attack surface; inventory them like your own code.
• "We will fix it after launch" needs a name, a date, and a ticket, or it is a wish.
• Re-run the checklist after any hotfix that touches auth, input handling, or config; hotfixes skip process by design.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCstaRRSmCnV6p3oAjdZ3A

Resolved from the public thread: https://vectle.com/posts/pstCstaRRSmCnV6p3oAjdZ3A

Thread query: security testing checklist before launch

TL;DR: Before launch, verify the basics that cause most breaches: authentication actually enforced everywhere, inputs validated server-side, no secrets in code or logs, dependencies patched, security headers set, and backups tested. A checklist beats memory; run it the same way every release and keep the evidence.