Menu
DocumentationGrafana CloudCost management and billingReduce costsSynthetic Monitoring costs
Grafana Cloud RSS

Reduce Grafana Cloud Synthetic Monitoring costs

You can reduce your Synthetic Monitoring costs by running fewer test executions. Refer to how Synthetic Monitoring usage is calculated for an explanation of test executions and how they are measured.

Review your usage

You can review usage on the Billing and Usage dashboard on the Synthetic Monitoring Usage Details panel. You can configure usage alerts from the panels displayed on the Billing and Usage dashboard to notify your team when activity exceeds expected levels.

Reduce your usage

There are three ways to reduce test execution volume:

Reduce execution frequency

The default frequency of a check is one execution per minute, but it can be changed to as low as once per hour. This is the easiest and most effective way to reduce costs. Unless you require high frequency monitoring, changing from once per minute to once every five minutes reduces costs by 80% with minimal loss of fidelity.

Caution

If you increase the interval of your checks, be sure to review any alert or recording rules that rely on the data: the ranges used may need to be adjusted upward to account for data being collected less often. As a rule of thumb, ranges should be at least 2.5x the interval of the check. This ensures that Prometheus functions like rate() have at least two samples to work with.

For example, if a monitor is changed from running every 2 minutes to every 10 minutes, an alerting rule containing the following would no longer work as expected: rate(probe_all_success_count[5m]). The 5m range query would have one data point at most, and sometimes no data. To work as expected the range should increase to 25m (2.5x the new check interval of 10m): rate(probe_all_success_count[25m])

Use fewer probe locations

For critical tests on public probes, at least three locations are recommended. This reduces the noise and volatility of running tests on the internet. If a monitor is non-critical or is run on a private probe within your network, one or two probes may be sufficient.

If you use Synthetic Monitoring for uptime monitoring (as opposed to over-the-internet latency monitoring), consider using only probe locations that are in close proximity to your service and/or use the same cloud service provider. For example, if your service runs in AWS consider using public probes that run in AWS. This provides a more reliable signal using a smaller number of probe locations.

Reduce or cap execution duration

Test executions are metered in one-minute increments, rounded up to the nearest minute: a test lasting one minute and five seconds counts as two executions. This is typically only a concern for multi-step tests such as MultiHTTP and scripted checks: the vast majority of protocol-level tests such as HTTP, DNS, and ping, take less than a few seconds to run.

To avoid the costs of long-runnings tests:

  • In k6 scripted checks, avoid calling functions like sleep() frequently or for long periods, which can extend the duration of test execution.
  • Review the steps in the workflow to see if any can be run in parallel rather than sequentially, using functions like http.asyncrequest().
  • If you expect a test to run within a certain period of time, use a timeout value to cap the execution duration and avoid unexpected costs. For example, if you expect a test to run in 30 seconds, setting a timeout of 59 seconds on the check prevents a single test run from counting as 2 executions if it unexpectedly runs longer than 1 minute.