AI Usage Dashboards: A Restart Can Reset the Counter

An AI service’s dashboard showed fifteen completed requests. A little later it showed two. An automated summary calls that a sharp fall in customer activity. Before changing the marketing plan, ask whether the number was a cumulative counter and whether the process restarted.

A smaller reading can describe a change in the measurement’s starting point. For business owners reviewing AI usage, the important work begins with understanding what the metric accumulates, when it resets and how the report turns successive readings into a claim.

Distinguish an accumulating counter from a snapshot

The official Prometheus metric-types documentation defines a counter as a cumulative metric that increases or resets to zero on restart. Examples include requests served and tasks completed. It distinguishes this from a gauge, which can represent a quantity that legitimately falls, such as the number of currently running processes.

For a fictional AI writing service, “requests completed since this process started” and “requests currently in progress” would therefore answer different questions. A fall in the first reading calls for an investigation of the counter’s continuity. A fall in the second could simply mean work has finished.

The title on a dashboard should help the reader make that distinction. “Usage” is too broad for this example. Ask for the counted event, unit, scope and starting point. A cumulative service reading does not become an hourly customer total merely because it appears on an hourly report.

A small example shows why subtraction fails

Consider an original hypothetical sequence from one process: at 09:00 its counter reads 12; at 09:01 it reads 15; at 09:02 it reads 2; and at 09:03 it reads 5. Assume a restart reset the counter between the second and third readings.

Subtracting the first reading from the last gives 5 − 12 = −7. That is the change between those displayed endpoints. It cannot represent a negative number of completed requests under the stated counter definition.

Suppose, for the first possible history, no further requests completed after the reading of 15 and before the reset. There were three completions from 12 to 15, two after the reset to reach 2, and three more to reach 5: eight completions after the first reading.

Now suppose four additional completions occurred after the reading of 15 but before the reset. The displayed sequence would be unchanged, yet that second history contains twelve completions after the first reading. The sampled values alone cannot distinguish the two histories.

These are constructed examples, not observations from a customer system. Their purpose is to expose the missing information. Recognising a reset prevents a misleading negative total; it does not, by itself, reveal every event that occurred between observations.

Use counter-aware queries, with their qualifications

Prometheus’s increase function documentation says that it adjusts for breaks in a counter’s monotonic increase, including resets caused by target restarts. It also extrapolates across the requested time range. Consequently, its result can be non-integer even when the counter increases in whole-number steps.

For someone commissioning a dashboard, those two behaviours belong in the explanation. The function accounts for resets, while its time-range result can involve extrapolation. A decimal display is not automatically evidence that part of a request occurred.

Ask the person maintaining the monitoring system to show the actual query, selected interval and applicable metric definition. Do not replace the expression with a new one solely because an AI assistant supplies plausible syntax. Check it against the deployed system and its data.

No Prometheus query was executed for this article. The numerical histories above are reasoning examples, not predicted outputs of increase. Their exact event counts should not be presented as the function’s computed result.

Keep the measurement and the business interpretation together

Imagine a fictional owner, Ada, receiving a report that says demand declined during a deployment. She could first ask whether “demand” refers to submitted requests, completed requests, active customers or a process counter. Those definitions permit different conclusions.

For her proposed review, preserve the raw readings and note the deployment time. Then ask whether a restart is confirmed and whether the report’s calculation handles it. If the available evidence does not settle the period’s exact total, say so rather than inventing the missing activity.

Ada might also need records tied to individual completed jobs for a reconciliation question. In that case, specify which records are authoritative for that task and compare the same event definition over the same period. A monitoring chart can prompt the investigation without answering every record-level question.

The distinction matters for decisions. A request to investigate a reset is different from a claim that fewer customers wanted the product. Keep the business conclusion provisional until the evidence addresses the particular question being asked.

Specify the event before reviewing the trend

Prometheus’s instrumentation guidance recommends counters for accumulating events and gauges for snapshots of state. It advises using a rate for understanding how quickly a counter increases, rather than relying on the raw counter alone.

For the fictional writing service, decide exactly when the completion event is recorded. Is it after text is generated, after the output is saved or after a defined review step? These are proposed questions for the owner and developer, not claims about a particular product’s implementation.

There is a related issue in MaryChuks.com’s guide to counting jobs and attempts separately. A counter that records attempts cannot answer a completed-job question without the appropriate relationship between those events. Handling resets does not repair an unsuitable event definition.

Give the report an evidence note

• Metric: the event counted, unit and scope.
• Continuity: the counter’s starting point and any confirmed reset in the interval.
• Calculation: the query and time range, including any extrapolation.
• Coverage: relevant gaps or unresolved evidence.
• Interpretation: the business question this result can support.

A proposed AI summarisation instruction could be: “Explain this metric using the supplied definition, query and restart notes. Distinguish observed readings from calculated results. Identify missing evidence and do not infer customer demand from a counter reset.”

Review the resulting summary against those materials. If a source is absent, obtain it or retain the uncertainty. The instruction is an editorial review aid, not a validated safeguard against every reporting error.

A useful usage report makes its starting point visible. When a counter drops, investigate what restarted and how the interval was calculated. That gives a business owner a sounder basis for action than treating every smaller number as a smaller appetite for the service.

Sources

• Prometheus: Metric types — counters and gauges.
• Prometheus: Query functions — increase, resets and extrapolation.
• Prometheus: Instrumentation — event counters and state gauges.

Living documentation checked on 5 November 2026; the cited pages do not state a publication date. Ada, the service and the numerical histories are illustrative. No production dashboard or Prometheus instance was tested.