Skip to main content
Use this guide to understand what drives your Wherobots bill and how to keep costs low — particularly when you’re getting started, testing queries, or evaluating the platform.

​
How Wherobots billing works

Wherobots charges based on Spatial Units (SUs) consumed over time. The main factors in Spatial Unit consumption are:
  1. Runtime size — Larger runtimes consume more Spatial Units per hour.
  2. Runtime duration — The longer a runtime stays active, the more you pay.
  3. Runtime region — Some regions have different Spatial Unit rates.
Billing starts when a runtime is fully provisioned (shown as Status: Running with a green dot 🟢 icon in the UI) and stops when the runtime is destroyed. Charges are prorated to the exact minute — if you use a runtime for 13.4 minutes, you pay for 13.4 minutes.
Smaller runtime + shorter session = lower bill. You have direct control over both.Choose your runtime size intentionally and always destroy notebooks when you’re done.
For more details on Spatial Units and how runtimes are priced, see How is runtime usage measured?.

​
Cost management strategies

The following strategies will help you manage costs, especially during the early stages of exploration and development.

​
Start with a Tiny or Micro runtime

When you’re exploring Wherobots for the first time — writing queries, testing workflows, or confirming that your logic is correct — use the smallest runtime available:
RuntimeMax Spatial Units / hrBest for
Micro1Lightweight exploration, simple queries
Tiny5Initial development, testing, query validation
These runtimes are sufficient for developing and validating queries against sample data or smaller datasets. Only scale up to a larger runtime (Small, Medium, etc.) once you’ve confirmed that your query logic is correct and you need faster execution on larger datasets.
Community Edition Organizations are limited to the Tiny runtime. Professional and Enterprise Editions have access to the full range of runtime sizes.

​
Destroy notebooks when you’re done

A running notebook consumes Spatial Units even if you’re not actively using it. This is the most common source of unexpected charges. To avoid surprises, always destroy notebooks when you’re done with them:
  1. Go to Wherobots Cloud.
  2. Scroll to the Notebooks section.
  3. Click Destroy on any active notebook instances you no longer need.
While Wherobots has an idle timeout (defaulting to 45 minutes), you are still charged for minimum resources while the notebook is idle. Always destroy notebooks you’re not using to fully stop billing.

​
Use idle timeout as a safety net, not a strategy

Wherobots lets you configure an idle timeout (15, 45, or 120 minutes) that reduces resource consumption when a notebook sits unused. However:
  • Idle timeout does not destroy the notebook — it reduces but does not eliminate charges.
  • Treat idle timeout as a safety net for those times when you forget to clean up, not as your primary cost-control measure.

​
Monitor your usage

Use the Workload History dashboard to track resource consumption across your Organization:
Workload History table view
From here you can:
  • Identify the amount of Spatial Units consumed by each Job, SQL Session, or Notebook.
  • Filter Jobs, SQL Sessions, or Notebooks by Owner, Region, and Type.
  • Toggle among different time ranges (last 24 hours, last 7 days, last 30 days).
  • Filter by name or ID to find specific workloads.
  • Identify usage spikes and long-running sessions.
For more information, see Workload History.

​
Monitor your Job Run history

Within the Workload History dashboard, each Job Run includes a detailed view of its resource consumption:
Consumption metrics
For more information see, Manage Job Runs.

​
Scale up only when needed

Follow this progression as you move from testing to production: 
Micro / Tiny → Small → Medium → Large → X-Large
PhaseRecommended runtimeWhy
Exploring the platformMicro or TinyLowest cost while you learn
Developing & testing queriesTinyEnough power for iterative development
Running on full datasetsSmall or MediumBalance of cost and performance
Production workloadsSize to your needsMatch runtime size to your SLA and data volume
If a Tiny runtime isn’t delivering results fast enough, move up one size at a time rather than jumping to a large runtime.

​
Quick-reference checklist

Use this checklist to keep costs under control:
  • Start small — Use Micro or Tiny runtimes during initial testing.
  • Validate first — Confirm your query logic on a small runtime before scaling up.
  • Destroy when done — Destroy notebook instances as soon as you’re finished.
  • Review usage — Check the Workload History dashboard regularly.
  • Scale intentionally — Only increase runtime size when you have a clear performance need.

​
Cost example

Let’s discuss a concrete example to illustrate how costs can add up and how to manage them:
  • A Tiny General Purpose runtime in the us-west-2 region consumes up to 5 Spatial Units per hour.
  • For example, if Spatial Units are priced at $1.50 each (see Wherobots Pricing for current rates), that comes to a maximum of $7.50 per hour.
If you ran a test session for 15.25 minutes, the cost would be calculated as follows: $7.50/hr×(15.25 min60 min)=$1.91\text{\$7.50/hr} \times \left(\dfrac{15.25\,\mathrm{min}}{60\,\mathrm{min}}\right) = \text{\$1.91} As you can see, a 15-minute test session on a Tiny runtime costs under $2.
Don’t forget to clean up: However, leaving this same runtime idle for a full 8-hour TTL window could cost up to $60 — even if you stop working after 15 minutes.To avoid unexpected charges, always destroy notebooks when you’re done.