How Storacle Works
Once a night, Storacle's engine measures your org's storage and keeps the reading. Here is what it measures, who it runs as, how long it keeps what it finds, and how it knows when Salesforce's numbers have stopped moving.
The nightly run
Scheduling the engine during setup registers one daily job, and the person who schedules it becomes that job's owner. Every night the run is performed as the owner. Scheduling twice does not create a second job, so the org never measures twice in a night.
The run reads and writes in system mode. A measurement is a statement about the org, not about the person the job happens to belong to, so what the owner's own record access lets them see does not change what the engine counts. That is also why the Storacle Engine permission set grants almost nothing: system mode needs no grant on the objects it measures.
The owner still needs a few things of their own: the Run Storacle Engine permission, plus API Enabled, View Setup and Configuration, and View Roles and Role Hierarchy, which the record-count read is checked against. The Permissions page covers where each one comes from.
Run Engine Now
A run started from Run Engine Now on Storacle Home has nothing to do with the schedule. It runs as whoever pressed the button, and the records it writes are theirs. It needs the same permissions of them that the nightly run needs of the job's owner.
A measurement is a reading of the org as it is when the run happens. The engine cannot go back and measure an earlier day, so a night without a run is a gap in the history that nothing fills later. Keep the job's owner an active user who holds those permissions.
What one run does, in order
Each step is its own transaction. A step that fails is logged on the run, and the steps after it still run, so one failure does not cost the night.
- 1
Collect
Reads the org's storage limits and every tracked object's record count, and writes the day's measurements.
- 2
Aggregate
Rolls completed weeks and months of daily measurements into snapshots, and longer periods from those.
- 3
Forecast
Projects data and file storage forward. Only a run in a paid org, trial included, performs this step. A free org's run leaves it out entirely, so no forecast is ever computed there.
- 4
Alert
Raises and resolves alerts from the night's figures.
- 5
Clean up
Deletes measurements, snapshots, logs, and resolved alerts that are past their retention.
- 6
Check health
Judges whether the numbers the run just collected can be trusted. See the health check below.
- 7
Close the run
Records how the run went on its run record, then reports the two usage counts described on the Security page.
The usage counts are covered on the Security page.
What it measures, and how
Data and file storage for the whole org
The org's used and allowed data storage and file storage come straight from the limits Salesforce reports for the org. Nothing is estimated at this level: these are Salesforce's own figures, read every night.
Record counts for every tracked object
Each object's record count comes from the org's own record-count API, the statistic Salesforce keeps for every object. The engine reads it through your org's own domain, so the call never leaves your org. New objects are picked up as they appear. Object families that do not use data storage, such as field history, sharing, feeds, tags, and change events, are left out.
File storage is measured for the org as a whole. Salesforce does not attribute it to objects, so neither does Storacle.
Sizes, estimated from the counts
An object's size is its record count times a storage factor: the bytes each of its records is taken to use. Every object gets its factor when Storacle first sees it, from a packaged exception for the objects known to differ, or from the org-wide factor otherwise. The factor is stored on the object, so correcting one object changes that object's figures and leaves every other object's history alone.
Snapshots and tiered retention
Storacle keeps its own history the way it suggests you keep yours: fine-grained while it is recent, summarized as it ages. Each tier is coarser than the one before it and kept longer, and the nightly cleanup deletes whatever has passed its retention.
Daily measurements
One reading per tracked object and one for the whole org, every night. These are the raw history every chart and forecast starts from, and they are kept for the shortest time: out of the box, 90 days for each object's readings and a full year for the org's.
Weekly and monthly snapshots
Built from the daily measurements once each week or month completes, for every object and for the org. They outlive the daily readings they summarize, so the trend is still there after the detail is gone.
Quarterly and yearly snapshots
Rolled up from the monthly snapshots. Quarterly snapshots are kept longest of all the expiring tiers, and yearly snapshots never expire.
Measurements, snapshots, alerts, and engine runs are ordinary custom objects you can report on, on the free tier as well as the paid one. The Pricing page lists what each tier includes.
The health check: making sure the counts are fresh
The record-count statistic comes from Salesforce, not Storacle, so Storacle checks it on every run in the unlikely event that it stops refreshing. If it did, every object's count would sit still, night after night, while the records underneath kept changing. A run collected that way would look perfectly healthy and be wrong.
So every run ends by checking its own numbers. It picks the objects that have been most active recently and compares each one's live count with the statistic it just recorded. A statistic that has not moved across recent nights while the live count has moved past tolerance is the signature of a stall. One object whose statistic did move shows the statistics are refreshing, and clears the night.
The night is flagged, not hidden
A suspect run is marked on its run record, and that night's object measurements are marked Stale Statistics, so anything reading them knows the counts may repeat a frozen value. When the statistics start moving again, the catch-up jump is not read as real growth.
One delayed retry per night
A flagged night schedules a single retry for later. The retry asks Salesforce for the counts again, and only if they have moved does it re-measure the night, as a new run that points back at the flagged one. The flagged run keeps its flag as the record that the stall happened.
An alert when it persists
When stale nights run on past a threshold, Storacle raises a stale statistics alert, and it resolves itself once the counts recover. That alert is free. The Alerts page covers it alongside the rest.
Settings
A seat allows you to adjust many settings that change the way Storacle works. Those settings apply to the engine and system as a whole and apply regardless of seats. A seat just lets you change them.
Reading settings is free
Every section of the settings in Storacle Configuration is visible to everyone who can open it. Without a seat, the sections a seat unlocks are shown read-only rather than hidden, so you can see what you would be tuning.
Diagnostics is free to change
The log level is in its own section, and changing it needs no seat. When something goes wrong, turning logging up is the first thing support will ask for, so it can't sit behind a purchase.
What you set while paying survives a lapse
Changing data retention, measurement and discovery, the Salesforce contract, forecasting, growth alerting, the health check, or notifications needs a seat. If the org stops paying, the values already set stay in force; only changing them stops. A retention horizon you lengthened keeps protecting your history instead of the next cleanup deleting it.
Still have questions?
If the engine is not running, or a run did not do what this page describes, the Troubleshooting page is the place to start. For anything else, contact support.