Every year, Indian e-commerce founders spend the September to November window pouring effort into two things: the ad plan and the creative plan. The email calendar is locked, the influencers are briefed, the Meta budget is loaded, the Google Ads pixels are firing. And every year, on the actual big day, a large percentage of that spend is quietly wasted because the site itself is not ready for the traffic it is paying to receive.
This is not a marketing failure. It is a technical one. And it is almost always avoidable if the checklist below is worked through, in order, in the six weeks before Diwali. In 2026, that means starting now, not in the last week of October. With Diwali on 8 November and Navratri opening on 21 October, a founder or CTO reading this today has roughly six weeks. Enough time, but only just.
What follows is not the marketing checklist. There are plenty of those. This is the technical readiness audit you should hand to your dev team, your Shopify partner, or your in-house engineering lead this week. Eight areas. What to test. What to fix. What to freeze. Ordered roughly by how much revenue is at risk if you skip it.
1. Load capacity: can the site actually take the spike?
The most common Diwali failure is the simplest one. The site works fine at normal traffic, and falls over at ten times normal traffic. Founders discover this in real time, at 11 AM on the day of the sale, when the checkout starts returning 503s and the customer support inbox fills up in eight languages at once.
The fix is to load-test before the traffic arrives, not during. This means simulating peak concurrent user counts, peak checkout throughput, and peak database query volume, and then finding the point at which each of them breaks. The number you care about is not average response time. It is the tail: the ninety-fifth and ninety-ninth percentile response times under the worst realistic load.
Checklist for this area:
- Peak concurrent visitor target is defined, based on last year's Big Day traffic multiplied by your growth plan, then multiplied again by 1.5 as a safety margin.
- Load test run against a production-mirror environment, not a stripped-down staging site.
- Hosting tier confirmed, or upgraded, based on the load test results. Auto-scaling rules tested, not just configured.
- CDN in front of every static asset, including product images, CSS, JavaScript and fonts. Cache hit ratio measured and above 90 percent.
- Database indexed for the specific queries your product-listing and search pages actually make. A single missing index on a hot query is enough to bring the site down.
2. Page speed, tested on real Indian phones and real 4G
A Lighthouse score of 92 on your engineer's MacBook, on wired broadband, in a Chrome incognito window, means nothing. The buyer opening your site is on a mid-range Android phone, on 4G, in Nashik or Salem or Ludhiana, with three other apps eating memory. Test where your traffic actually lives, or you are testing the wrong thing.
Core Web Vitals matter for two reasons in this window. First, Google uses them in ranking, which decides how much organic Diwali traffic you get. Second, a slow site loses buyers before they see the product. Every additional second of load time on the product page loses a meaningful share of intent.
Checklist for this area:
- Largest Contentful Paint (LCP) under 2.5 seconds on a mid-range Android device over 4G, tested on the product detail page and the checkout page specifically.
- Interaction to Next Paint (INP) under 200 milliseconds, particularly on the add-to-cart and apply-coupon actions.
- Cumulative Layout Shift (CLS) under 0.1, especially on the product listing page where late-loading images commonly shift the layout.
- Product images served in modern formats (WebP or AVIF), sized appropriately, and lazy-loaded below the fold.
- Third-party scripts audited. Every marketing pixel, chat widget and A/B test tag is a load cost. Kill anything that is not directly earning.
3. Payment gateway resilience: the single most expensive failure point
If your site is up and your payment gateway is down, you have lost the customer. Not delayed them. Lost them. The average Indian buyer, mid-purchase, on a limited-time festive offer, does not wait, refresh, or come back. They leave, and often they leave for a competitor whose gateway is working.
This is the one area where redundancy is not paranoia. It is table stakes. Every serious Indian e-commerce site during festive season runs on at least two payment gateways with automatic fallback, plus native UPI intent, plus COD available on eligible orders.
Checklist for this area:
- Two payment gateways integrated, with clear routing rules and tested automatic fallback if the primary gateway returns errors.
- UPI intent flow tested end to end on the top four UPI apps used in India.
- Card payment flow tested for all major banks, with 3D Secure working correctly on both success and failure paths.
- Cash on Delivery available where the fulfilment operation can support it, with pincode-based eligibility rules.
- Payment retry logic tested. A failed transaction should not disappear silently: the customer sees a clear error and a working retry button, not a spinner.
4. Cart and checkout stability under load
The cart is where every marketing rupee cashes in, or does not. Under festive load, three specific things tend to break: session state gets lost so the cart empties itself, coupon validation slows to a crawl so buyers abandon, and inventory holds do not release properly so the same unit gets promised twice. All three are silent failures. The buyer just leaves.
Checklist for this area:
- Session persistence tested. A cart built at 11 AM should still be there when the buyer returns at 4 PM, whether they were logged in or not.
- Guest checkout available. Forcing account creation on a first-time festive buyer is a self-inflicted conversion loss.
- Coupon and discount code validation responds in under 500 milliseconds even at peak load. Slow coupons kill checkouts.
- Address form pre-fills from pincode. A buyer who has to type city and state manually is a buyer who half the time drops off.
- Order confirmation page and email send reliably, every time. A missing confirmation triggers a support ticket at best and a chargeback at worst.
5. Inventory and order management sync
Overselling during festive season is the single most reputationally damaging failure a D2C brand can commit. The buyer places an order, pays, receives a confirmation, and then gets a cancellation email 48 hours later because the item was out of stock. That customer is gone, and often the story of that cancellation is on Twitter or Instagram within the day.
The technical fix is real-time inventory sync between the website, the OMS, the warehouse management system, and any marketplace listings that share stock. If any one of those links is a nightly batch update instead of a live push, the festive week will expose it.
Checklist for this area:
- Stock levels on the site update within seconds of a sale, not minutes.
- Marketplace listings (Amazon, Flipkart, Myntra) share inventory with the D2C site in real time, or have clear stock reservation rules per channel.
- Low-stock alerts trigger before you sell the last unit, not after.
- Backorder or pre-order flow works cleanly for SKUs you know will spike, with honest delivery date communication.
- Fulfilment partners notified of festive volume projections so their side of the operation scales with yours.
6. Analytics, tags and pixel integrity
The point of measuring is to know what worked, so next year is better. In practice, most Indian e-commerce sites finish festive season with broken tracking, contradictory numbers between GA4 and the ads platform, and no clear picture of which campaigns actually earned. The forensic work of understanding what happened is impossible if the sensors were off.
This is a pre-sale problem, not a post-sale one. Fix tagging in October so November data is trustworthy.
Checklist for this area:
- GA4 e-commerce events (view_item, add_to_cart, begin_checkout, purchase) firing on every product, tested on production, not just in Tag Assistant.
- Meta Pixel and Google Ads conversion tags firing, with server-side tracking configured for iOS traffic where client-side is unreliable.
- Enhanced conversions enabled in Google Ads so login-required actions still attribute correctly.
- UTM structure locked and documented, so every campaign source, medium and content variant is trackable back to revenue.
- A single trusted dashboard for the founder or CMO to look at during the sale, drawn from clean data, not from three tools that disagree.
7. Security, fraud and rate limiting
Festive traffic hides bot traffic. Attackers know that your fraud filters get looser under load because false positives cost real revenue, and they time card-testing runs, credential stuffing attempts, and inventory-hoarding bots for exactly this window. Volume becomes their camouflage.
Checklist for this area:
- Rate limiting on the checkout endpoint, on the login endpoint, and on the coupon-application endpoint, tuned to festive traffic patterns not normal ones.
- Bot protection at the edge (Cloudflare, Akamai or equivalent), with festive-week rules reviewed and hardened.
- Suspicious order flagging rules in place: unusual quantities, mismatched billing and shipping, fresh accounts placing high-value orders, all reviewed manually before dispatch.
- SSL certificates verified not to expire during the sale window. This has ended more Big Days than it should have.
- Admin panel access reviewed. Every unused developer, agency or ex-employee account revoked before the sale, not after.
8. Code freeze, incident playbook, and the rollback plan
The single most common cause of a Big Day outage is a deploy that was not needed. A well-meaning engineer, on the morning of the sale, ships a small change to fix a small bug, and takes the whole site down. The fix is discipline, not talent. Freeze the code, keep the freeze, and only break it if the site is already broken.
Checklist for this area:
- Code freeze declared from a specific date, in writing, communicated to every developer, agency and vendor. Fifteen October is a reasonable line for a Diwali 8 November sale.
- Emergency-only deploy protocol defined: who can authorise, what the review is, how rollback works.
- Incident runbook written for the six or seven failures most likely to happen, in the language of the person on call, not the person who wrote the code.
- On-call rotation staffed for the full sale window, including nights, with clear escalation paths.
- Rollback plan tested. Not documented, tested. A rollback you have never rehearsed is a rollback you do not have.
How to actually run this checklist
Nobody has time to do all eight areas perfectly. That is not what this checklist is for. It is a triage tool. If your site has been through last year's festive season and you know which areas held up and which did not, start with the ones that failed last year. If this is your first serious festive season, start from the top of the list: load and speed before payments, payments before analytics, analytics before security.
The order below is the order we would work through it if we had six weeks and had to choose:
- Weeks 1 to 2 (now to 8 October): Load capacity, page speed, payment gateway resilience. The three areas where the failure is loudest and the revenue loss is largest.
- Weeks 3 to 4 (9 to 22 October): Cart and checkout stability, inventory and OMS sync. The silent failures. Also the highest-effort fixes because they touch multiple systems.
- Week 5 (23 to 29 October): Analytics, tag integrity, security, and fraud rules. Everything that needs to be right before real money starts moving.
- Week 6 (30 October onwards): Code freeze in effect. Runbook rehearsals. On-call warmed up. Do not ship anything unless the site is broken and the fix is smaller than the risk.
“A festive-season outage is almost never bad luck. It is almost always a checklist item that was skipped in September.”
Need a hand working through this audit?
If your audit surfaces problems your current partner cannot fix, MagicWorks builds and hardens e-commerce sites for Indian brands, and our AI-native website practice is built around the speed and architecture this checklist depends on.
Explore E-commerce Development,
book a discovery call and we will look at your site with you.
Swapnil Ughade is the Founder and Managing Director of MagicWorks IT Solutions Pvt. Ltd., an AI-first digital marketing agency based in Pune. Founded in 2009 and now in its seventeenth year, MagicWorks builds AI-native websites and runs commission-tier performance marketing for businesses across India and international markets. Swapnil has 17+ years of experience across digital marketing, web development and AI consultation.
