vulkro-sf org platform-limits
Every live-org command (vulkro-sf org ...) is part of Pro: Live-org audit (sf-live-org), permissions, session, MFA, sharing, packages and trust, read from the org itself. On Free it stops before doing any work, prints what it needs and where to get it, and exits 1. See Pricing.
Audits platform governor and limit utilization health
(SF-LIMITS-001 / -002).
A hot limit is both an availability risk and an abuse signal. A runaway integration or an attacker flooding the API can exhaust the org for everyone, and the utilization curve is often the first place that shows up.
Synopsis
vulkro-sf org platform-limits --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. |
--format <fmt> | table | json | table | Output format. |
--verbose, -v | flag | off | Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins). |
What gets read
The org-wide limits REST resource
(GET /services/data/vXX.0/limits).
Tracked governors include daily API requests, Bulk API batches, async Apex executions, data and file storage, and platform events.
What gets reported
| Rule | Severity | Threshold |
|---|---|---|
SF-LIMITS-001 | High | Utilization at or above 90 percent. Signal platform-limit-utilization-critical. |
SF-LIMITS-002 | Medium | Utilization at or above 75 percent. Signal platform-limit-utilization-elevated. |
Examples
vulkro-sf org platform-limits --target-org my-prod
vulkro-sf org platform-limits -o my-prod --format json > limits.json
Exit codes
0- no findings.1- posture findings reported.2- error.
Scope and honesty
The org is read locally through your own authenticated sf CLI login;
nothing is sent anywhere. Only the org-wide limits envelope is read: no
records, no metadata.
This is a point-in-time snapshot of utilization at the moment you run the command, not a trend. A limit at 92 percent late in the day may be entirely normal for that org, and a limit at 10 percent this morning says nothing about the afternoon. The rule reports the number against a threshold; interpreting it against the org's normal load is the operator's job.
High utilization is a signal that something is consuming the limit, not proof of abuse.
Where to go next
- vulkro-sf limits-report - the limits-focused report surface.
- vulkro-sf org event-monitoring - API burst and error-storm anomalies that can explain a hot limit.