SquaredUp pricing model explained

If you've found this blog via our pricing page, or have been considering upgrading, and you're trying to work out what to buy, this short write-up should help explain how the key pricing elements of SquaredUp work.

TL;DR

Users are the folk who can access the full functionality of SquaredUp: this isn’t just your admins and authors, but any users who need to browse and interact with the dashboards and data — e.g. drilling down from a top-level dashboard to explore a problem. We call these ‘interactive users’. These users can have different permissions based on access control, and they can access dashboards without the need for sharing.

Shared dashboards are dashboards via a link, or sent to email, Slack or Teams on a schedule. Shared dashboards can typically be viewed by anyone with the link. Viewers do not need to be an ‘interactive user'.

Monitoring queries are the way we measure monitoring. Monitors can be configured on a tile and run in the background. They can be configured to run on different intervals depending on your need — for example a daily interval for monitoring costs, or a 5-minute interval to monitor CPU performance. Most tiles require a single query to evaluate, but more complex tiles may use multiple data streams and hence make multiple requests. As an example, a simple monitor running every 15 minutes would use 2,880 queries a month.

Objects are the things our plugins "index" from your data sources... your lambdas from AWS, pipelines from Azure DevOps, agents from Zendesk. They're the familiar entities you'll see in a search, when exploring the Map, or building a tile. The more plugins you connect, and the larger your environment, the more objects you'll consume.

Users vs sharing

When should you pay for interactive users and when should you use shared dashboards?

In general, shared dashboards are great when:

• The dashboards are viewed by many users (e.g. an org-wide dashboard)
• The dashboards are used on a wall monitor (no need for authentication)
• You do not know exactly who will view the dashboard (eg send out a link via email, in another web page, or on a messaging platform like Slack)

Users are needed for:

• Users who need access to many dashboards
• Users who need to drilldown into multiple levels of dashboards
• Users who need to explore and analyse using the data in SquaredUp
• Users who need to create or edit dashboards

Monitoring queries

Monitoring queries are consumed when you set up monitors on your tiles. Monitors can be used from simple notifications to end-to-end application monitoring.

How many do I need?

This will depend on how many monitors you configure, how complex your monitors are, and how often you run.

Here’s a table of some typical monitoring that can be achieved with 200,000 queries:

If you’re going to use SquaredUp for serious monitoring — eg monitoring infrastructure or applications — then you’ll likely need larger quotas up to or beyond 1,000,000.

What happens if I run out?

Cutting you off is in nobody's interest. Instead we allow overages, and in addition, our friendly Customer Success team keeps a proactive eye on all of our customer usage. If it looks like you're flying a bit close to the sun, we'll always try to help you out. Typically, it's as simple as quickly reviewing your noisiest monitors and reducing their frequency, but in some cases, it might need to be a subscription change.

In any case, we're here to help you get the most out of SquaredUp.

Objects

SquaredUp is built on top of a knowledge graph, which in effect, is a database designed to store objects and their relationships. With some magic on top, our graph correlates those objects across tools, shining light on connections you might have been unaware of, or at the very least, enabling you to bring otherwise siloed data together.

You're already very familiar with the power of knowledge graphs, assuming you've ever used Google. Type Picasso into the search box and you'll see a "people also searched for" section populated not with random people from France, but with similarly regarded cubist painters. Google uses the properties of an object to build a web of meaningful relationships to objects that share similarities.

Our graph does this too.

What's the benefit?

Let's say you're running an Azure Function that's monitored by Dynatrace. Both our Azure and Dynatrace plugins will create objects for that function. Our graph figures that out and joins them together, so when you search for and then drill into that object, you'll see a mix of data from both Azure and Dynatrace all in one view. If you're getting advanced, you could use our graph to find all your Azure Functions that are, or aren't, monitored by Dynatrace. Like I said... magic.

The first time you're likely to interact with your objects is in our Tile Editor. When you're creating a tile, you pick a data stream and then the object(s) you're interested in. The list of objects you see comes from the graph, and is always filtered to match the data stream you chose.

How are objects created?

When you connect a new plugin, the first thing it does is "index" your objects. We find out what your tool knows about, and then create records in our graph representing those objects and their relationships. Indexing happens every 12 hours after that, to ensure our graph is reflective of any changes in the source data.

How many objects will be created?

In short, "it depends".

The plugin you're connecting to and the size of your environment are the primary factors here. Let's work through a quick example...

You're a large enterprise running hundreds of apps in Azure. When connecting to Azure, we'll create objects for each subscription and resource group, and all the resources they contain.

Let's say you have 50 teams of 10 people. Each team has their own subscription, each of which contains a couple of resource groups per person, containing 10 resources each.

50 subscriptions + 1,000 resource groups + 10,000 resources = 11,050 objects.

Now let's say most of that is controlled via pipelines in Azure DevOps. Again, each team has their own project, containing varying numbers of pipelines, environments, test plans...

50 projects + 150 pipelines + 250 environments + 500 test plans = 950 objects

So I really wasn't kidding when I said "it depends".

Our largest Enterprise customers tend to need around 150,000 objects, while our more typical Enterprise customers tend to need around 50,000 objects.

Sizing in your own environment

The best way to understand your need to is simply to try it out for real.

Get in touch with us, either through our Support Team or via your sales rep, and we can help you do this for real via a generous Enterprise trial. Connect all your plugins, build a load of dashboards, go crazy with monitoring, and just see what it looks like.

I hope this helps demystify Users, Shared Dashboards, Queries, and Objects.