Browser Storage Footprint & Change Monitor

What does Browser Storage Footprint & Change Monitor do?

Monitor browser storage changes after website releases. This Actor renders supplied public pages in Playwright Chromium and compares hashed localStorage and sessionStorage key sets with the last complete observation. Try the prefilled https://example.com/ input to establish a harmless baseline.

It complements browser network and cookie diagnostics when a new application release, analytics integration or tag manager starts creating new storage keys. Apify provides API access, scheduled runs, dataset exports and integrations, so you can add these observations to a release checklist.

Why use this browser storage monitor?

• Detect new or removed storage-key identifiers after deployments.
• Keep separate monitors for production, staging and individual release-critical pages.
• Observe what scripts create during a fresh visit.
• Keep storage values and raw key names out of reports.

A CHANGED result is a change signal for investigation. It is not a compliance verdict or evidence of malicious behavior.

How to use it

1. Enter one to three public HTTP(S) page URLs.
2. Choose a stable monitorKey such as homepage-daily.
3. Run once to create the baseline.
4. Run again with the same URL and observation settings.
5. Read changeStatus and localChanges/sessionChanges. Schedule serial runs for recurring checks.

The Actor visits each page in a fresh context with no supplied login, consent or session. The page's own scripts may create storage normally. No consent buttons are clicked.

Input

Field	Default	Meaning
urls	example.com	Up to 3 public pages
monitorKey	default	1-64 letters, digits, underscores or hyphens
settleMs	1500	Delay after DOM readiness, up to 5000 ms
navigationTimeoutSeconds	25	Per-page navigation limit, 5-45 seconds
maxKeysPerStorage	100	Key cap per area, 1-200

Example:

{"urls":["https://example.com/"],"monitorKey":"homepage-daily","settleMs":1500}

Changing the exact URL, query string or observation settings creates a separate baseline. Credentials in URLs and destinations on private networks are rejected.

Output

Each page produces a dataset row. Complete observations use status CHECKED and changeStatus BASELINE_CREATED, UNCHANGED or CHANGED. Over-cap or inaccessible storage uses INCOMPLETE and does not replace its previous baseline. Navigation failures use ERROR.

{"status":"CHECKED","changeStatus":"UNCHANGED","page":"https://example.com/[path:8a5edab282632443]","local":{"accessible":true,"observedCount":0,"keyIds":[],"truncated":false},"localChanges":{"added":[],"removed":[]},"sessionChanges":{"added":[],"removed":[]},"chargeEligible":true}

Key IDs are deterministic SHA-256 identifiers. They do not reveal raw names directly, but hashing is not encryption: known names can be matched by hashing guesses. No storage values are read or returned. Page paths are hashed and queries omitted from reports.

You can download the dataset in formats such as JSON, CSV, HTML and Excel. OUTPUT contains requested, succeeded, incomplete, failed and charged counts. The persistent baseline resides in the separate Actor-specific named key-value store.

Price and operating limits

Proposed price: USD 0.010 per complete stored page check. Initial baseline and unchanged complete checks are useful observations and are billable. Error and incomplete reports are free. Actual pricing is displayed in the Pricing tab after monetization is configured. Platform charges depend on your plan.

The browser makes only GET/HEAD requests, blocks images/fonts/media and limits network transfer. A complete empty footprint is expected on the prefilled example page.

Limitations and support

Only the main frame's localStorage/sessionStorage key sets are observed. No cookie, IndexedDB, cross-origin iframe, value-change or logged-in-session audit is performed. Late writes after settle time are not observed. Region, browser state, experiments and nondeterministic key names can cause changes between visits. Storage-disabled pages are incomplete rather than empty.

Run one monitor at a time to avoid competing baseline writes. Reuse stable settings for comparable observations. Contact the developer through the Issues tab with sanitized details if an audit fails.