Actor Billing Auditor

You migrated. Did you migrate correctly?

Pay-per-event pricing is easy to configure and easy to get wrong. This Actor reads your own Actors' pricing configuration and run history and tells you where the money is leaking — runs that charged but produced nothing, runs that cost more than they earned, and tier ladders that quietly do nothing.

On its first run against its author's own Actors it found a net-losing Actor and 7 silently-billed empty runs.

Your token

Your token is used only for read API calls during the run and is never stored or transmitted to third parties.

That is enforced in code, not just promised:

• The API client refuses any request that is not a GET, so no code path — present or future — can modify your account.
• The token is held in a closure. It is never written to the dataset, never written to the key-value store, and never logged. Anything that does escape into an error message is passed through a scrubber that replaces the token with <redacted-token> first.
• There are no external services. The only host contacted is api.apify.com.

The token field is marked isSecret, so Apify encrypts it at rest in the run's input.

Create a token at Settings → API & Integrations. Read access to your Actors is all it needs.

What it checks

#	Check	Basis
1	Zero-result charged runs — runs that charged an event while writing nothing to the dataset	run history
3	Margin audit — charged revenue vs the real platform cost of each run, with the dominant cost driver named	run history
4	Pricing consistency — identical tier prices, inverted tier ladders, unpriced events	configuration
—	Ex-rental detection — whether the Actor was repriced off the retiring rental model, and when	configuration
—	Rental deadline — for Actors still on rental, days remaining before the automatic conversion	configuration

Duplicate-start detection and operational-risk checks are planned for v0.2.

The findings that matter most

Zero-result charged runs. An Actor that charges a per-GB start fee bills on every attempt. When a selector breaks or a credential expires, the Actor keeps "succeeding", keeps billing, and delivers nothing. It is invisible in aggregate revenue because revenue goes up.

Negative margin. Compute is rarely what sinks an Actor — residential proxy transfer usually is. The audit reads the run's real usageUsd breakdown rather than modelling cost from memory and runtime, so the figure is what you were actually billed, and it names the driver.

Pricing structure. Identical prices across every tier (tiering configured but doing nothing) and inverted tier ladders. These are rarer — about 1.3% of live pay-per-event Actors — but they are exact findings, not estimates, and they persist silently once set.

Case study: our own fleet

The first run of this Actor against its author's own Actors found:

• a net loss of $10.57 across 55 runs (−$0.19 per run, 44 of 55 losing money), with residential proxy transfer at 98% of cost and compute under 10% — a compute-based cost model would have called it healthy
• 7 of 55 runs (12.7%) charged but wrote zero rows, billing for no data
• on a second Actor, a FAILED run that still billed four start events

Then it found a bug in itself: its own first run predated its pricing, and the audit scored that as a loss. Fixed, with a regression test — ex-rental Actors would have hit the same thing on every pre-migration run.

How to read the numbers

The report separates two kinds of finding, and the distinction is important:

• Configuration findings are facts. Pricing structure and rental status are read directly from your Actor's configuration. They are exact and complete.
• Run findings are observations. Apify does not expose your users' runs to you — GET /acts/{id}/runs returns only runs you started. So run-derived findings are a diagnostic sample of your own runs, not a billing statement.

A defect found in your own runs is still real: your users hit the same code path. But the dollar figures are labelled "observed" and are never extrapolated to a fleet total, because that would be guessing.

Input

Field	Type	Default	Notes
apifyToken	string, required, secret	—	Your own Apify API token
actorIds	array	[]	Leave empty to audit every Actor on your account
lookbackDays	integer	30	Run-history window, 1–365

Output

Dataset — one record per Actor: actorId, name, pricingModel, findings[] (each with severity of CRITICAL / WARNING / INFO), estimatedLossUsd, margin, zeroResult, exRental.

Key-value store — OUTPUT holds the fleet summary plus the full report; REPORT.md holds a ready-to-read markdown report.

Pricing

Pay per event, one actor-audited event per Actor for which a full report was produced.

• A failed Actor is not charged.
• An invalid token exits before the first charge — the run fails rather than "succeeding" empty.
• On the free tier the audit is limited to 3 Actors per run.

Still on rental pricing?

Rental sunsets on 2026-10-01. An Actor with no new pricing configured by 2026-09-30 is automatically converted to pay-per-usage, which pays the developer nothing — rental paid 80% of the monthly fee, and that becomes $0. Configuring future pricing before the deadline prevents this; the 14-day notice does not have to elapse first, and an Actor with no subscribers can reprice with immediate effect.

For the migration modelling itself, use Apify's own free rental to pay-per-event calculator — it is purpose-built, and it can submit per-user price overrides to Apify support, which this Actor cannot. This audit tells you whether the pricing you landed on is actually sound.

Development

npm install
npm test

Charging is exercised in simulation mode against the real code paths, so the billing gate is tested without billing anyone:

$ACTOR_TEST_PAY_PER_EVENT=1 ACTOR_USE_CHARGING_LOG_DATASET=1 node src/main.js

Charge events are then written to the local charging_log dataset instead of being billed.