Quota and Usage

The Two Allowances

Both are shown with the limit, what has been spent against it, what remains, and, for the monthly one, when it returns. History is shown per month, which is the granularity the counters are kept at.

Raising a limit is the only way past the lifetime one. See Configuration Options.

What Counts as a Unit

A unit is a discovery: one installation found. That is one new-JVM event from the Agent, or one row of an AMT scan report.

A refresh event, which the Agent sends to say that something it already reported is still running, does not draw on the discovery allowance. It draws on a separate ceiling twenty times larger, which exists to catch a runaway Agent rather than to meter your usage. So an estate that restarts its JVMs every night cannot exhaust its discovery allowance without discovering anything. Settings > Quota and Usage shows this ceiling as a Refreshes bar once half of it is used.

Units are counted from the rows a delivery produced, not from the size of the file. A malformed line that never became a row was never accepted and was never counted.

Re-ingesting the kept deliveries is charged like new data, and the lifetime usage keeps the replayed units afterwards. Raise both limits before you start a replay. See Re-ingesting the kept deliveries.

How the Check Works

The allowance is checked before a delivery is taken, and never in the middle of one.

Whatever is accepted is counted in full, even where it carries you past the line. A modest overage is the price of never abandoning half-ingested data. What stops is the next delivery: it stays sealed and unread in the inbox, and is picked up when the allowance returns. Nothing is lost, and nothing has to be re-sent.

Usage is recorded when a delivery is accepted, never derived from the stored dataset. A figure derived from the data would hand the allowance back whenever something was removed, and an allowance you can recover by deleting data is not an allowance. The counters are durable, so a restart does not hand you a fresh allowance either.

The counter starts from zero and is never seeded from the stored dataset. Refresh events are merged into the runs they belong to when they are ingested, so the stored rows are not the count of what was accepted.

When an Allowance Runs Low or Out

At 80 percent of an allowance, and again once one is spent, your installation shows a notice in the web interface.

The notice states the consequence rather than only the percentage, and it distinguishes the monthly allowance from the lifetime one. The monthly notice states the date the allowance resets, in UTC. The lifetime notice names no date, because that allowance never resets.

You can dismiss a notice for the rest of the day on that device. Dismissing the 80 percent notice does not silence the one that follows when the allowance is spent: those are different claims, and the second is the one somebody would be sorry to have missed.

A threshold crossing is written to your application log. It is not an audit-log entry, because nobody performed it. See Audit Log.

What a Spent Allowance Looks Like

This is the part worth reading before it happens. When an allowance is spent:

Nothing is broken and nothing errors, which is exactly why the notice matters. Two places will tell you afterwards:

A wave records its outcome from the observations inside its watch window. A machine nothing was observed from is reported as not reported, whatever silenced it, which is another reason to know when your installation stopped ingesting. See A wave is watched, then given an outcome.

Reading Usage From Automation

Quota and usage are shown in the web interface, under Settings > Quota and Usage. The integration API does not carry them. See The Integration API.