India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Dev/Test Scheduling: Run Non-Production Cloud Only When Teams Work
Dev/test scheduling stops or scales down non-production cloud environments outside the hours they are used, so development, QA, UAT and training systems are billed for working time instead of all 168 hours of the week. NTSPL designs time-zone-aware schedules on AWS, Azure and Google Cloud covering VMs, databases and Kubernetes, with self-service wake-up so teams are never blocked.
Delivered on
In scope
Why Non-Production Schedules Get Abandoned Within a Month
A typical non-production environment is used about 50-60 hours a week: weekdays from 9 a.m. to 8 p.m. IST, plus occasional weekend releases. It is billed for 168. In most Indian product and services companies, non-production is 30-45% of total cloud spend, so running it around the clock wastes roughly a fifth of the entire bill. Teams know this, yet schedules fail in practice: a tester arrives to find UAT down, a database takes 20 minutes to start, a US client's QA team works through the IST night, and within a month someone tags everything 'always-on'.
NTSPL designs scheduling as a service teams trust, not a policy imposed on them. Each environment gets a schedule matching its users' time zones, a start sequence that brings databases up before application tiers, and a one-click or chat-command wake-up for out-of-hours work that expires automatically. Exceptions are visible and time-bound, so 'always-on' becomes a decision with a cost, not a default.
Estates Where Scheduling Pays Back Fastest
Signals you need Dev Test Scheduling
- Non-production accounts, subscriptions or projects account for more than 25% of cloud spend.
- Dev, QA or UAT VMs and databases show CPU near zero between 9 p.m. and 8 a.m. IST and at weekends.
- Previous shutdown scripts exist but most environments are tagged as exceptions.
- Dev and test Kubernetes clusters keep full node pools running overnight.
- Teams work across IST and one or two overseas client time zones, and fixed schedules keep clashing.
When to choose something else
- Non-production environments are ephemeral already, created per pull request and destroyed after tests: optimise pipeline efficiency instead.
- The environment is a performance or soak test rig running multi-day tests: schedule around test campaigns, not daily hours.
- Assets have no current users at all: that is idle cleanup, not scheduling, so delete rather than schedule them.
Environment Components Brought Under Schedule
Virtual machines and scale sets
EC2, Azure VMs and Compute Engine stopped or scaled to zero; Auto Scaling groups, VM Scale Sets and managed instance groups set to zero capacity out of hours.
Databases
RDS and Aurora stopped or scaled to zero ACUs, Azure SQL serverless auto-pause, Cloud SQL activation policy changes, with start ordering before dependent apps.
Kubernetes clusters
Dev and QA node pools scaled to zero on EKS, AKS and GKE, or whole AKS clusters stopped, with system pools kept minimal.
Supporting services
Bastions, build agents, self-hosted runners, analytics notebooks and GPU workstations included in schedules.
Wake-up and override
Chat or portal command to start an environment for a set number of hours, logged and auto-expiring.
Schedule, Sequence and Wake-Up Control Design
Time-Zone-Aware Environment Scheduler
Environment tags define schedule, time zone and start order; a scheduler service evaluates them every 15 minutes and stops or starts resources in dependency sequence. A chat-based wake-up path lets users override for a fixed period, and all actions feed a savings and exception report.
Select any component
Time-Zone-Aware Environment Scheduler: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Native Scheduling Tools on Each Cloud
Stopped RDS instances restart automatically after seven days, so NTSPL pairs long weekend schedules with a re-stop job, or moves suitable dev databases to Aurora Serverless v2 with auto-pause.
Whole AKS dev clusters can be stopped, which removes node cost while keeping configuration; NTSPL uses this for QA clusters not needed overnight.
Instance schedules handle VM start and stop natively; Cloud SQL and GKE node pools need Cloud Scheduler jobs calling the APIs, which NTSPL containers in one Workflows definition per environment.
Schedule Windows, Start Order and Exception Rules
Choosing schedule windows
Start from login and CPU data, not assumptions. A common IST schedule runs 8:30 a.m. to 8:30 p.m. on weekdays: 60 of 168 hours, a 64% cut in run time. Teams serving US clients often need 2 p.m. to 2 a.m. IST instead. NTSPL keeps a small catalogue of named schedules, such as ist-office, ist-extended and us-overlap, rather than letting each team invent one.
Stop, scale to zero or deallocate
Stopping a VM keeps its disks billed but removes compute cost; on Azure, the VM must be deallocated, not just shut down from the OS, to stop compute billing. Scale-set and node-pool capacity should go to zero rather than stopping instances individually. For databases, prefer serverless auto-pause where the engine supports it, because it needs no schedule and resumes on first connection.
Start order and readiness
Most complaints about scheduling are really about start order: application tiers boot before the database and fail health checks. Define three or four start tiers per environment and gate each on health. Schedule start 30-45 minutes before the working window so environments are ready when people arrive. Track readiness time as a service level, not an afterthought.
Override and exception governance
Give users an easy wake-up command with a time limit, typically 2-8 hours, and make permanent exceptions hard: they need an owner, reason and end date, reviewed monthly. In NTSPL rollouts, keeping exceptions under 10% of non-production environments is the strongest predictor of savings that last beyond the first quarter.
Environment-by-Environment Scheduling Rollout
Usage profiling
Login, CPU and request data per environment analysed to set candidate schedules and identify time-zone needs.
Tagging and grouping
Environments grouped with start tiers and schedule tags applied through IaC or policy.
Scheduler and wake-up build
Native scheduler deployed, sequenced start workflows written, and chat wake-up integrated with Teams or Slack.
Pilot with two teams
Two volunteer teams run on schedules for two weeks; start-time and override data used to tune windows.
Estate-wide rollout and reporting
Remaining environments onboarded in waves, exceptions registered, and weekly savings reports started.
What you receive
Scheduling Savings and Developer Experience Measures
| KPI | Typical target |
|---|---|
| Non-production compute cost reduction | 45-65% |
| Environments under schedule | Above 85% of non-production |
| Environments ready by schedule start | Above 98% of weekdays |
| Permanent exceptions | Below 10% of environments |
| Median wake-up time on demand | Under 10 minutes |
Scheduling Pitfalls That Block Teams
| Risk | How NTSPL prevents it |
|---|---|
| Developers blocked when they need to work late or on weekends. | Self-service wake-up via chat with a 10-minute target, and named extended schedules for teams that work late regularly. |
| Scheduled shutdown interrupts a long-running test or migration. | A 'hold' tag delays shutdown by up to 12 hours, and running pipelines are checked before stop. |
| Environments fail to start cleanly because of start order or expired credentials. | Health-gated start tiers and a daily readiness check that alerts the owning team before working hours. |
Scheduling non-production or moving to ephemeral environments: which is better?
Ephemeral environments, created per branch or pull request and destroyed after tests, are the better end state for stateless services with fast, automated provisioning. They remove idle time completely. But most Indian enterprises have long-lived UAT and integration environments with seeded data, third-party sandboxes and manual testers, which take hours to rebuild. For those, scheduling is the practical answer. NTSPL usually does both: schedule shared long-lived environments now, and move developer and feature environments to ephemeral patterns as pipelines mature.
Key facts: Dev Test Scheduling
Dev Test Scheduling in Practice
2 Dev Test Scheduling scenarios, from Edtech (competitive-exam preparation app and live doubt-solving) and Gaming studio (mobile and PC game development), plus related platform case studies.
Test-prep edtech puts 52 Azure environments on schedules developers actually keep
Mobile gaming studio schedules GPU build farms and dev GKE pools across three time zones
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
Dev Test Scheduling: Frequently Asked Questions
How much does dev/test scheduling save, and how much effort is it?
Non-production compute typically falls 45-65%, which on estates where non-production is a third of spend means 15-20% off the total bill. A rollout takes eight to ten weeks. NTSPL charges a fixed fee for design and build; ongoing operation is light, mostly the monthly exception review.
Do stopped VMs still cost money?
Disks, snapshots and reserved IPs remain billed; compute does not. On Azure the VM must be deallocated to stop compute charges. On AWS, public IPv4 addresses are charged even when unattached. NTSPL factors these residual costs into the savings estimate so expectations are accurate.
How do schedules handle Indian public holidays?
The scheduler reads a holiday calendar, including national holidays and regional ones such as Ganesh Chaturthi in Pune or Pongal in Chennai offices, and keeps environments off on those days unless a team requests otherwise. Release freeze calendars can force environments on during critical testing windows.
What about databases that take long to start?
Schedule them to start 30-45 minutes before application tiers. Where the engine supports it, move dev databases to serverless options with auto-pause, such as Aurora Serverless v2 or Azure SQL serverless, which resume on first connection and need no schedule at all.
Can scheduling work with Savings Plans or reservations?
Yes, but plan them together. Scheduled usage is not steady, so non-production compute should generally not be covered by commitments sized to 24x7. NTSPL recalculates the commitment baseline after scheduling, often reducing planned purchases. In one typical case, scheduling removed a third of the compute that a planned Savings Plan would otherwise have covered.
Does scheduling affect security monitoring or log collection?
Stopped resources generate no new logs, which is acceptable. What matters is that monitoring agents restart correctly and that stopped periods are not misread as outages. NTSPL tags scheduled resources so alerting suppresses expected-down states. CERT-In's 180-day log retention is unaffected, because stored logs are kept centrally.