Technical validation (1-2 days before)
Overview
This phase focuses on verifying that all Phase 1 optimizations are working correctly and your systems are ready for high-traffic conditions. This is validation only; avoid making major changes this close to your event. Think of this as your final systems check before launch.
Key principle: Measure twice, cut once. If issues are discovered now, evaluate whether fixes can be safely implemented or if the event should be delayed.
Prerequisites
- Phase 1 optimizations completed and tested on staging
- Staging environment with current production data (you can update your staging environment with a data sync from production if needed)
- Test payment gateway credentials configured
- Monitoring systems active and configured
- Team contact information documented
- Rollback procedures tested and documented
Timeline guidance
- 48 hours before: Complete all staging validation tests
- 24 hours before: Final production spot checks and go/no-go decision
- 12 hours before: Change freeze begins, final cache pre-warming
- 6 hours before: Final monitoring dashboard checks
Validation checklist overview
This phase validates four critical areas:
- Cache system functionality: Ensuring Edge Cache and exclusions work correctly
- Customer purchase flows: Verifying end-to-end conversion paths
- Payment and email systems: Confirming revenue-critical functions
- Performance baselines: Validating Phase 1 improvements are effective
Detailed validation procedures
Each task includes key information to help with delegation, timelines, and prioritization. We recommend you review this entire guide before planning your Phase 2.
1. Cache state and exclusions
Verify cache purge procedures
[Developer] [10-15 min] [Blocker]
What you’re checking: Your ability to quickly clear cache during the event if needed.
How to test:
- Using Pressable Cache Management Plugin:
- Go to Cache Control in admin bar
- Test “Purge Edge Cache” button and verify confirmation
- Test “Flush Object Cache” button and verify confirmation
- Note time required for cache to rebuild (visit a few pages)
- Via Pressable Control Panel:
- Navigate to Performance section
- Test Edge Cache purge functionality
- Test Object Cache flush functionality
- Document exact navigation path for emergency use
WP-CLI verification:
# Test cache flush commands
wp cache flush
wp edge-cache purge --domain=yoursite.com
# Verify cache cleared
curl -I https://yoursite.com/ | grep x-ac
# First request should show MISS, second should show HIT
Success criteria: Cache purge completes within 30 seconds, pages rebuild cache on next visit showing x-ac: HIT.
If this fails: Do not proceed without working cache controls. This is important for managing traffic spikes.
Pre-warm critical paths
[Anyone] [10-15 min] [Critical]
What you’re checking: Key pages are cached and ready to serve traffic immediately.
How to test:
- Clear browser cache and cookies
- Visit pages in this specific order:
- Homepage (wait for complete load)
- Main shop page
- Top 5 category pages
- Top 10 product pages
- Any promotional landing pages
- Open Developer Tools (F12) > Network tab
- Refresh each page and verify
x-ac: HITin response headers
WP-CLI verification:
# Automated pre-warming via bash script
for url in "/" "/shop/" "/product-category/featured/" "/product/bestseller/"; do
curl -s -o /dev/null https://yoursite.com${url}
sleep 2
done
# Verify cache hits via bash script
for url in "/" "/shop/" "/product-category/featured/" "/product/bestseller/"; do
echo "Testing ${url}:"
curl -I https://yoursite.com${url} | grep x-ac
done
Success criteria: All critical pages show x-ac: HIT on second visit.
If this fails: Identify which pages aren’t caching properly. Check for logged-in user cookies or cart sessions interfering with cache.
See our guide on batcache here and our guide on edge cache here. See our guide on how WooCommerce’s order attribution feature interacts with caching here.
Confirm cache exclusions
[Developer] [5-10 min] [Blocker]
What you’re checking: Dynamic pages that must not be cached are properly excluded.
How to test:
- Add a product to cart
- Visit these pages with Developer Tools open:
- /cart/ – should show
x-ac: BYPASSor nox-acheader - /checkout/ – should show
x-ac: BYPASSor nox-acheader - /my-account/ – should show
x-ac: BYPASSor nox-acheader
- /cart/ – should show
- Verify cart contents update immediately when changed
- Test that checkout fields save/validate without cache interference
WP-CLI verification:
# These should NOT show HIT
curl -I -H "Cookie: woocommerce_items_in_cart=1" https://yoursite.com/cart/ | grep x-ac
curl -I -H "Cookie: woocommerce_items_in_cart=1" https://yoursite.com/checkout/ | grep x-ac
Success criteria: Dynamic pages show BYPASS or no cache header, updates appear immediately.
If this fails: Critical issue; caching user-specific data will cause cart mixing and checkout failures.
2. WooCommerce-specific validation
Verify HPOS compatibility
[Store Owner] [15-20 min] [Blocker]
What you’re checking: High-Performance Order Storage is enabled and all extensions are compatible.
How to test:
- Navigate to WooCommerce > Settings > Advanced > Features
- Confirm “High-Performance Order Storage” is enabled
- Check compatibility status shows all green checkmarks
- Place a test order and verify it appears in:
- WooCommerce > Orders (new HPOS interface)
- Order confirmation email is sent
- Payment gateway dashboard shows transaction
- Test order actions: edit, refund, duplicate
- Verify any order-related plugins work correctly
Success criteria: HPOS enabled, all critical extensions compatible, test orders process correctly.
If this fails: Either resolve incompatibilities or disable HPOS if time doesn’t allow for fixes. Document the decision.
Test cart fragments optimization
[Developer] [10-15 min] [Critical]
What you’re checking: Cart fragments are disabled on non-essential pages per Phase 1 optimization.
How to test:
- Clear browser cache and cookies
- Open Developer Tools –> Network tab
- Filter by “admin-ajax”
- Visit these pages and verify NO cart fragment requests:
- Homepage
- Shop page
- Category pages
- Individual product pages (before adding to cart)
- Visit cart/checkout and verify fragments work where needed
Success criteria: No woocommerce_get_refreshed_fragments requests on browsing pages, fragments work on cart/checkout.
If this fails: Review cart fragments code from Phase 1. This significantly impacts PHP worker load.
3. Payment and communication systems
Validate payment gateway flows
[Store Owner] [30-45 min] [Blocker]
What you’re checking: All payment methods process correctly under various scenarios.
How to test:
- For each active payment gateway:
- Enable test/sandbox mode
- Place order with simple product
- Place order with variable product
- Test with different shipping zones
- Verify order status updates correctly
- Confirm payment appears in gateway dashboard
- Test failure scenarios:
- Declined payment recovery
- Abandoned cart with payment pending
- Network timeout during processing
- Check webhook endpoints:
- Verify webhook URLs in each gateway settings
- Test webhook delivery (check gateway logs)
- Confirm webhooks complete within 5 seconds
Success criteria: All payment methods process successfully, webhooks respond quickly, failure scenarios handled gracefully.
If this fails: Do not proceed without working payment processing. This directly impacts revenue.
Email deliverability testing
[Developer] [20-30 min] [Critical]
What you’re checking: Transactional emails reach customers reliably.
How to test:
- Verify SMTP configuration:
- Check SMTP plugin settings (WP Mail SMTP, Post SMTP, etc.)
- Confirm authentication is working
- Test connection to email service
- Send test emails:
- Order confirmation to various email providers (Gmail, Outlook, Yahoo)
- Password reset email
- Customer invoice
- Admin notification emails
- Check email headers (using a service like https://www.mail-tester.com/)
- SPF record passing
- DKIM signature valid
- No spam flags
- Test email rate capacity:
- Verify provider limits can handle expected order volume
- Check queue handling for bulk sends
WP-CLI verification:
# Test email sending
wp eval 'wp_mail("test@example.com", "Test Subject", "Test message");'
# Check mail log if plugin installed
wp db query "SELECT * FROM wp_mail_log ORDER BY id DESC LIMIT 5;"
If using an SMTP plugin, see our guide to email deliverability and SMTP plugins here.
If using Pressable’s default transactional email (not recommended for high volume sites), see our guide covering necessary DNS records here.
Success criteria: Emails delivered within 2 minutes, SPF/DKIM passing, no spam folder placement.
If this fails: Critical issue; customers won’t receive order confirmations. Resolve SMTP issues or delay event.
4. Performance validation
Mobile checkout validation
[Store Owner or QA Tester] [20-30 min] [Critical]
What you’re checking: Mobile users can complete purchases smoothly.
How to test:
- Using real mobile devices (not just browser emulation):
- iPhone Safari
- Android Chrome
- Tablet browsers
- Test complete purchase flow:
- Product browsing and search
- Add to cart interaction
- Cart review and updates
- Checkout form completion
- Payment method selection
- Order completion
- Check for issues:
- Buttons too small or close together
- Forms difficult to complete
- Keyboard covering important elements
- Payment buttons not responding
- Page jumping during input
Success criteria: Mobile checkout completes smoothly on all tested devices, forms are easy to complete.
If this fails: Document specific issues. Minor UI issues may be acceptable, but checkout blockers require fixes.
Verify performance baselines
[Developer] [15-20 min] [Important]
What you’re checking: Phase 1 optimizations are working and performance meets targets.
How to test:
- Check key metrics against Phase 1 baselines:
- Ex. Autoload data size:
wp option list --autoload=on --format=total-bytesshould be under 1MB
- Ex. Autoload data size:
- Test page performance:
- Homepage TTFB (cached): Should be under 400ms
- Cart page TTFB (uncached): Should be under 700ms
- Checkout page TTFB (uncached): Should be under 700ms
- Database performance:
- Run Query Monitor on key pages (be sure to disable Query Monitor when done testing)
- Homepage: Under 30 queries
- Product pages: Under 50 queries
- Checkout: Under 100 queries
Success criteria: All metrics meet or exceed Phase 1 targets.
If this fails: Review which optimizations aren’t working. Minor degradation may be acceptable with documentation.
5. External dependencies
Third-party service status check
[Anyone] [5-10 min] [Important]
What you’re checking: Critical external services are operational.
How to test:
- Check service status pages (documented during Phase 1):
- Payment gateways (Stripe, PayPal, etc.)
- CDN provider status
- Email service provider
- Any integrated shipping services
- Bookmark these status pages for event day:
- status.stripe.com
- paypal-status.com
- your SMTP provider
- Test API connectivity:
- Place test order to verify payment API
- Send test email to verify SMTP
- Check any custom integrations
Success criteria: All services showing operational status, APIs responding normally.
If this fails: Consider backup payment methods or document known issues for event day monitoring.
Staging environment hygiene
[Developer] [5-10 min] [Nice-to-have]
What you’re checking: Staging site won’t pollute analytics or get indexed.
How to test:
- On staging site, check Settings > Reading
- “Discourage search engines” should be checked
- View page source, verify
<meta name="robots" content="noindex,nofollow"> - Confirm analytics uses test property or is disabled
- Verify emails only send to test addresses
- Check that payment gateways use sandbox mode
Success criteria: Staging isolated from production systems, no risk of data pollution.
If this fails: Minor issue but fix to ensure clean analytics and testing data.
Go/no-go decision framework
Automatic “no-go” triggers
If any of these conditions exist, the event should not proceed:
Critical failures:
- Cache hit ratio below 85% on homepage, shop, or product pages
- Cart or checkout pages being cached (causing session mixing)
- TTFB above 900ms on uncached pages (cart, checkout)
- Payment gateway test failures on any active method
- Email deliverability below 95% or going to spam
- Database errors or connectivity issues
- Mobile checkout blocking issues
Infrastructure issues:
- No working cache purge mechanism
- Rollback procedure untested or unavailable
- Monitoring systems offline or misconfigured
- No emergency contact availability confirmed
“Proceed with caution” triggers
These issues warrant discussion but may not block launch:
Performance concerns:
- Cache hit ratio between 85-90% (document plan to improve)
- TTFB between 700-900ms on uncached pages
- Minor mobile UI issues that don’t block conversion
- Non-critical plugin compatibility warnings
Operational concerns:
- Limited team availability during event
- Third-party service degradation warnings
- Minor email delays (2-5 minutes)
- Documentation gaps in non-critical procedures
Decision documentation
Decision maker: [Name and role]
Backup decision maker: [Name and role]
Decision deadline: [Specific date/time]
Communication plan: [How go/no-go will be communicated]
Go decision requirements:
- All automatic no-go triggers cleared
- Risk assessment completed for any caution triggers
- Team availability confirmed
- Rollback plan tested and ready
- Stakeholder approval obtained
Pre-launch checklist
24 hours before
- All validation tests passed on staging
- Production spot checks completed
- Go/no-go decision made and communicated
- Team schedules confirmed
- Emergency contacts verified
12 hours before
- Change freeze in effect
- Final cache pre-warming completed
- Monitoring dashboards prepared
- Communication channels tested
- Rollback procedures reviewed
6 hours before
- Final performance check
- Payment gateways verified
- Email system tested
- Team briefing completed
- Launch plan reviewed
Handoff to Phase 3
Before proceeding to launch day operations:
Documentation required:
- Performance baseline metrics recorded
- Validation test results logged
- Known issues documented with severity
- Team assignments confirmed
- Emergency procedures printed/accessible
Technical readiness:
- All systems showing green status
- Cache properly warmed
- Monitoring actively tracking
- Rollback plan tested
- Emergency commands documented
Team readiness:
- All members aware of go decision
- Roles and responsibilities clear
- Communication channels active
- Escalation paths understood
- Schedule conflicts resolved
Next steps
With Phase 2 validation complete:
- Communicate go/no-go decision to all stakeholders
- Implement change freeze if proceeding
- Prepare Phase 3 monitoring dashboards
- Brief team on launch day procedures
- Get some rest: you’re ready for your event