A change log is useful when mobile data suddenly rises, an app stops connecting, or a phone reaches its limit earlier than expected. Instead of toggling many settings at once, record the period, symptom, baseline, and each test. The log should distinguish the phone's estimate from the carrier's billable record and should never include passwords, message contents, or full account identifiers.
Start with a precise symptom
Write one sentence that can be tested: “Usage increased by about two gigabytes during the current billing period,” “Only the navigation app fails on cellular,” or “Mobile data turns off when the device reaches its configured limit.” Record the date, location, active SIM, roaming state, Wi-Fi state, and any warning shown. Note whether the issue affects one app, all apps, or only background activity.
Capture both the carrier total and the device total before resetting anything. Apple's cellular settings documentation provides per-app usage and a Reset Statistics control, while warning that the carrier is the source for the most accurate current-period usage. Google's Pixel data-usage guide similarly says phone and carrier measurements can differ and recommends checking the carrier's measurements and plan limits.
Compare the right period
Align the device view with the carrier billing dates as closely as possible. If the phone's statistics cover a longer period, do not compare the totals directly. Record when statistics were last reset and whether the device changed SIMs. For a new monitoring period, save the baseline first, reset only after the user understands the effect, and set a reminder for the next billing-cycle boundary.
List the highest-usage apps and system services. For each, record foreground use, background access, large downloads, video calls, cloud synchronization, hotspot activity, automatic updates, and recent settings changes. Apple notes that Wi-Fi Assist can use cellular data when Wi-Fi is poor, and both Apple and Google provide app-level usage views. A change log should therefore include Wi-Fi quality and fallback features, not only time spent visibly using an app.
Record configuration changes one at a time
Useful entries include enabling Data Saver or Low Data Mode, changing an app's cellular permission, adding an unrestricted-data exception, changing the selected data SIM, enabling roaming, setting a warning or hard limit, installing an update, or restoring a device. Record the previous value, new value, reason, time, and expected effect.
On supported Pixel devices, a configured data limit can automatically turn mobile data off. Google also notes that some phone features stop working when mobile data is off. If a connection loss occurs near the threshold, check the limit before assuming the carrier failed. On iPhone, disabling cellular access for an app makes that service use Wi-Fi only. These are expected configuration effects, not necessarily faults.
Run a controlled test
Turn off Wi-Fi, confirm the intended SIM and mobile-data state, and test one low-data action in the affected app. Then restore Wi-Fi. If all cellular traffic fails, Google's Android connection guide recommends restarting, checking for a data indicator, testing Wi-Fi and cellular separately, and briefly toggling Airplane Mode. Record the result of each step before trying the next.
Avoid destructive troubleshooting in the first pass. Do not delete an eSIM, erase the device, reset all network settings, or change a carrier payment method merely to test a hypothesis. Escalate account, provisioning, coverage, and billing questions to the carrier.
Close the investigation honestly
At the next checkpoint, compare the device and carrier totals again. Mark the outcome as confirmed, improved but unconfirmed, unchanged, or unable to measure. A lower device estimate is not proof of lower billable usage until the carrier period also supports it. If one app remains unusually high, review its own download, media, backup, and call-quality settings.
A good mobile-data change log makes every conclusion traceable: what changed, what was measured, which period applied, and what evidence confirmed the result. It prevents repeated resets and helps the user reverse a setting that solved one problem by creating another.