vulkro-sf limits-report
Reports how much of each org limit is consumed and classifies every
limit into one of three bands: ok, warn, or critical. Limit
exhaustion is both an availability problem (jobs fail, the API stops
answering) and a security signal (a sudden spike in API consumption can
be the footprint of a bulk-extraction attack). This command surfaces
both before they turn into an incident.
Synopsis
vulkro-sf limits-report --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | The sf CLI org alias or username, as known to sf org login. |
--format <fmt> | enum | table | Output format: table (a banded, human-readable table on the terminal) or json (machine-readable, for a monitoring pipeline or a CI gate). |
What it does
limits-report reads the org's limit envelope (daily API requests, data
and file storage, async Apex executions, single-email and mass-email
allocations, and the other limits the platform exposes) and computes the
consumed percentage for each. Every limit is placed into a band:
ok: consumption is comfortably within the allocation.warn: consumption has crossed the warning threshold. The limit is trending toward exhaustion and warrants attention before the next peak.critical: consumption is at or near the ceiling. Action is needed now: the next workload may fail outright.
The banded view turns a flat list of numbers into a triage order: a
reviewer reads the critical rows first, the warn rows next, and
ignores the ok rows. In json form the bands make a clean CI gate
(fail the build if any limit is critical) or a monitoring alert.
Example
# Banded table on the terminal.
vulkro-sf limits-report --target-org my-prod
# JSON for a monitoring pipeline or CI gate.
vulkro-sf limits-report -o my-prod --format json > limits.json
Exit codes
0- report generated, no limit in thecriticalband.1- report generated, at least one limit reached thecriticalband.2- error:sfCLI not on PATH, alias not authenticated, network failure, or the org rejected the limits API call. The error message names the cause and the next step.
Privacy
limits-report reads only the org's limits envelope (the same data the
platform exposes through its limits API). No record-data SOQL is issued
and no metadata is retrieved. The OAuth token stays in the sf CLI
credential store on your machine.
Where to go next
vulkro-sf org status: confirm connectivity and identity before running this.- Event Monitoring and offline forensics: where a sustained API spike is correlated against the rest of the activity timeline.
- Salesforce limits API documentation: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_limits.htm