Skip to main contentClaim $5 in free credit — one-time, per account. Claim $5 free
Krova CloudKrova Cloud
Cloud Cost Optimization

When to Stop a Krova Cube Between Batch Jobs

Compare the idle gap with the extra time it takes to restart and finish a job. Then account for retained storage and the next run’s deadline.

DM
Dhruv Malaviya4 min read
Share
Frosted-glass server cube beside a clock with a turquoise pause symbol.

Imagine an export worker that finishes its morning report, then waits until the next batch. The dashboard shows the job is done, but the Cube is still running. Powering it off looks like an obvious saving until the next export has to wait for the worker, reload its cache, and retry a request that timed out while it was starting.

Stop a Krova Cube between jobs when the idle gap is longer than the extra billed compute time a stop and restart introduce, and the next run can still meet its deadline. For a burst of closely spaced jobs, keep the worker running through the burst and measure the longer gap afterward. The same retained disk still costs money either way.

Separate what stops billing from what stays

Krova quotes Cube rates by the hour and bills usage by the minute. Its Cube pricing page and billing FAQ describe the split: powering off stops the vCPU and RAM charges, while the retained disk continues to bill. An idle process or a stopped container can leave the Cube running. Check the Cube’s power state before counting the gap as a compute saving.

Hold disk size and retention constant for the first comparison. With the same disk retained over the same period, the disk line is common to both options. If you change the storage plan, include it separately. Krova’s snapshot guide describes snapshot storage and restore behavior. Check its cost and rehearse recovery before relying on a snapshot as part of a different retention plan.

Measure from the last useful write to the next ready worker

Pick a pair of representative jobs. Measure the idle minutes from the end of the first job to when the next would start on an already-ready worker. Then estimate the extra billed minutes in a stopped run over the same work. Include any billed drain and shutdown time beyond the warm baseline, the start and readiness delay that is billed, cache warm-up, and any extra job runtime or retries. Count each interval once. Also track total elapsed delay separately, because a wait can affect the deadline even when it doesn’t add compute charges.

For example, suppose the idle gap is 12 minutes and the stop/start path adds 4 billed minutes across shutdown, readiness and extra work. That saves about 8 compute minutes for the same Cube configuration and successful work. If the next gap is only 3 minutes and the extra billed work is still 4, stopping uses about one more compute minute. These are illustrative inputs. Use the observed usage and the current compute rate for your own estimate.

To estimate the compute difference, multiply the saved minutes by the vCPU-plus-RAM rate per minute. If your estimate uses the combined running rate, it also counts disk and overstates the saving. Compare the same successful outputs and include failed starts or retried work in your observation window.

Turn the numbers into a schedule

  • Long, predictable gap. Finish writing and verify the result is durable, stop the Cube, confirm its state, then start early enough to absorb the slow end of observed readiness times.
  • Short or irregular gaps. Keep the worker ready through the burst, or batch jobs within a delay your users can tolerate. Recheck the numbers after enough runs to include the slow ones.
  • Always-on dependency. Keep the Cube running if it also hosts a public endpoint, a queue or a database that must answer during the gap. If you split out a batch worker, include the added storage, traffic and operational costs in the decision.

Start with one low-risk batch and keep the clock or trigger somewhere that remains available while the Cube is off. Record power-state changes, worker readiness, job completion and the usage for the same interval. Krova’s n8n documentation describes start and stop operations you can use from an external workflow. Make the stop conditional on no work in flight and confirmed output, then check the next run’s result before making the schedule routine.

This guide was prepared with AI assistance using the linked documentation. The workload and timings are hypothetical and were not measured on a Cube.

Estimate your batch workload on Krova Cube

Use the current pricing to compare your measured running minutes and retained disk.

For AI agents:llms.txtsitemap

Related posts