Peak-season cloud capacity for Tally and mail

Quiet months hide weak capacity. GST weeks, year-end stock, and festival despatch put every idle remote session and under-sized seat on the same box. Plan upgrades before the queue forms — not after vouchers crawl.

Measure the real peak, not the licence list

Count who opens the live company between 10 AM and 1 PM on a filing week. Add the CA login and one owner seat. That concurrent number is what Tally on Cloud must carry. Named users on paper matter less than who is logged in together. Pair this with our note on concurrent user sizing.

Mail and remote access pile on the same week

Invoice PDFs, bank OTPs, and CA mail all spike when books are busy. If Workspace or Titan mail shares the same overloaded link as RDP, both feel “down”. Split pain: confirm mail deliverability separately from Tally latency, and close idle remote sessions overnight.

Upgrade early, test once

• Raise seats or CPU a week before the known peak
• Ask one branch to open reports at the new size during a quiet hour
• Keep a restore-tested backup the night before filing day

Changing capacity mid-GSTR rush is how lockouts get blamed on “the cloud” when the real issue was timing.

What to tell us on the ticket

Peak concurrent users, whether GST week adds outsiders, and whether mail and Tally share one pipe. That is enough for a practical footprint. Watch status if logins already feel odd, then contact KC Cloud or open a support ticket.