Org Limits Monitoring

Use this skill when an org needs proactive, automated visibility into its consumption of Salesforce platform limits. Unlike per-transaction governor limits that are enforced inline during code execution, org-level limits are shared ceilings that accumulate over time -- daily API calls, data storage, file storage, custom object counts, platform event delivery allocations, and more. When these limits are exhausted, the impact is org-wide: all integrations fail, all users are blocked from creating records, or platform events are silently dropped. The correct response is not reactive firefighting but proactive monitoring with automated threshold alerts.

Before Starting

• Which limits matter most? Not every org needs to monitor every limit. Identify the limits that are most likely to be exhausted given the org's usage pattern -- integration-heavy orgs should monitor API calls; high-growth orgs should monitor storage; event-driven architectures should monitor platform event delivery allocations.
• What is the current consumption baseline? Before setting thresholds, establish what "normal" looks like. A single day's snapshot is not enough -- collect at least two weeks of data to identify peaks and trends.
• What notification channels are available? Email is the simplest but most easily ignored. Platform Events can drive real-time LWC dashboards. Custom Notifications appear in-app. Outbound Messages or callouts can reach Slack or PagerDuty.

Core Concepts

Three Monitoring Surfaces

Salesforce exposes org-level limit data through three distinct surfaces, each with different strengths:

Surface 1: Apex OrgLimits Class

The System.OrgLimits class (available since API v41.0) provides a Map<String, System.OrgLimit> via OrgLimits.getAll(). Each OrgLimit instance exposes .getName(), .getLimit(), and .getValue() (current consumption). This is the best surface for scheduled Apex-based monitoring because it runs inside the org without consuming an API call.

Key characteristics:

• Returns a curated subset of limits, not every limit the REST resource exposes.
• Does not consume an API call (it is native Apex, not a callout).
• Available in all Apex execution contexts (trigger, batch, queueable, scheduled).
• The map keys are string names like DailyApiRequests, DataStorageMB, FileStorageMB, DailyAsyncApexExecutions, DailyBulkApiRequests, DailyStreamingApiEvents, HourlyPublishedPlatformEvents, and others.

Surface 2: REST API Limits Resource

GET /services/data/vXX.0/limits returns a JSON object with every org limit, including limits not available through the Apex class. Each entry contains Max and Remaining values.

Key characteristics:

• Most comprehensive surface -- exposes limits that OrgLimits.getAll() does not.
• Consumes one API call per invocation (factor this into API budget calculations).
• Ideal for external monitoring tools, middleware health checks, or CI/CD pre-deployment validation.
• Response payload is a flat JSON object with limit names as keys.

Surface 3: Setup -- Company Information

The Setup > Company Information page displays storage usage, API usage (last 24 hours), and feature limits in the UI. This is the only monitoring surface available to administrators without developer tooling.

Key characteristics:

• No programmatic access -- manual inspection only.
• Useful for one-time audits but not for proactive alerting.
• Shows a rolling 24-hour window for API usage.
• Storage breakdown shows data storage, file storage, and big object storage separately.

Threshold Alerting Architecture

The recommended architecture for proactive limit monitoring follows a simple pattern:

1. Scheduled Apex runs on a cron schedule (hourly or every 4 hours).
2. The job calls OrgLimits.getAll() and compares each limit's .getValue() against .getLimit().
3. When consumption crosses a configured threshold (e.g., 70% warning, 90% critical), the job fires an alert through one or more channels.
4. Alert channels include: Messaging.SingleEmailMessage for email, Platform Event publish for real-time dashboard updates, Messaging.CustomNotification for in-app bell notifications, or an HTTP callout to an external incident management system.

Custom Metadata for Threshold Configuration

Store monitoring thresholds in Custom Metadata Type records rather than hard-coding them. This allows administrators to adjust thresholds without code changes and supports per-limit configuration:

• Limit_Monitor_Config__mdt with fields: Limit_Name__c (text, matches the OrgLimit key), Warning_Threshold__c (percent, e.g., 70), Critical_Threshold__c (percent, e.g., 90), Enabled__c (checkbox), Notification_Channel__c (picklist: Email / Platform Event / Custom Notification / External).

Distinguishing From Related Skills

Recommended Workflow

1. Identify critical limits. Review the org's integration landscape, storage trajectory, and automation density. Select the 5-10 limits most likely to be exhausted. Common high-priority limits: DailyApiRequests, DataStorageMB, FileStorageMB, DailyBulkApiRequests, HourlyPublishedPlatformEvents, DailyAsyncApexExecutions.

2. Establish baselines. Run OrgLimits.getAll() or GET /services/data/vXX.0/limits daily for two weeks. Record peak consumption values. Use these peaks to set meaningful thresholds that avoid false alarms.

3. Design the monitoring job. Create a Scheduled Apex class that reads limit values from OrgLimits.getAll(), compares them against thresholds stored in Custom Metadata, and dispatches alerts when thresholds are crossed. Schedule the job at an appropriate frequency (hourly for API-heavy orgs, every 4 hours for storage-focused monitoring).

4. Configure alert routing. Map each limit to a notification channel. API limit breaches may need to reach the integration team via Slack webhook. Storage warnings may need to reach the data team via email. Critical alerts for any limit should page the platform team.

5. Build visibility. Create a Lightning Dashboard or LWC component that displays current limit consumption as gauges or progress bars. If the monitoring job publishes Platform Events, the dashboard can update in near-real-time without polling.

6. Test with realistic load. In a full sandbox, simulate high-consumption scenarios (e.g., run a bulk data load that consumes 80% of daily API calls) and verify that alerts fire correctly and reach the intended audience.

7. Operationalize. Add the monitoring job to the org's runbook. Document the escalation path for each alert severity. Review thresholds quarterly as org usage patterns evolve.

Modes of Engagement

Mode 1: Greenfield Monitoring Setup

The org has no limit monitoring in place. Start from Step 1 of the Recommended Workflow. Deliver a complete monitoring solution including Scheduled Apex, Custom Metadata configuration, alert routing, and a visibility dashboard.

Mode 2: Incident Response -- Limit Exhausted

A limit has already been breached. Start by identifying which limit was exhausted using GET /services/data/vXX.0/limits or Setup > Company Information. Determine the root cause (unexpected integration spike, data load, runaway automation). Implement emergency mitigation (disable the offending integration, archive data, increase allocation if contractually possible). Then proceed to Mode 1 to prevent recurrence.

Mode 3: Existing Monitoring Enhancement

The org has basic monitoring (e.g., a weekly manual check or a simple email alert) but needs more sophistication. Assess the current monitoring coverage, identify blind spots (limits not being tracked, thresholds too high or too low, alert fatigue from false positives), and enhance the solution incrementally.

Key Limit Categories

API Consumption Limits

Storage Limits

Platform Event Limits

Async Processing Limits

Official Sources Used

• Apex Reference Guide -- OrgLimits class and OrgLimit methods
• REST API Developer Guide -- Limits resource (/services/data/vXX.0/limits)
• Salesforce Help -- Monitor API Usage and Limits
• Salesforce Well-Architected Overview -- Operational Excellence pillar