Microsoft Lists keeps restarting — how to find and fix

Microsoft Lists repeatedly reloading or appearing to crash is usually caused by a client-side problem (browser cache, extensions, outdated app) or a list-level customization or automation that fails repeatedly. Start by reproducing the issue and collecting browser, app, and tenant details, then try safe fixes (reload, clear cache, test another browser or the Lists app). If restarts persist across browsers and devices, gather diagnostics and check tenant/service health and list customizations before escalating to Microsoft support.

What exactly is happening and how do I reproduce it?

Symptom

Microsoft Lists reloads / appears to crash / page refreshes repeatedly when a user opens or interacts with a list.

When it appears

• Immediately after opening a list view.
• When switching views (All items, custom view) or performing an action (edit, Quick Edit, sort, filter).
• Only for some users or devices, or tenant-wide.

How to reproduce reliably

1. Reproduce with the affected user account because the problem can be user-scoped.
2. Note the exact view: default view, filtered view, Quick Edit, or a custom view with formatting.
3. Try an action that consistently triggers the reload (open item, edit column, run flow).
4. Attempt reproduction in a second browser session using a private/incognito window.
5. Test the same list from a different machine or using Lists in Teams and the Lists web app.

What to capture first

• Exact error messages shown on screen (copy text). If the exact message varies, record the full screen or a screenshot.
• Whether the reload happens for one list or many lists.
• Whether it affects all users or only specific ones.
• Browser and version, operating system, and whether this occurs in Teams, the Lists web app, or the Lists app. Record the time the problem occurred and the account used.

Quick checks to note

• Is the list large or using many calculated or lookup columns? That can increase client processing.
• Are there custom column formats, custom forms (Power Apps), or flows attached to the list?
• Any recent tenant changes for that user (conditional access, MFA, policy rollouts) around the time the issue began?

Could this be my browser, app, or device problem?

Start on the client; this is the fastest place to stop restarts.

Steps to test and common fixes

1. Try a full reload and hard refresh.

Browser: open the list, press Ctrl+F5 (Windows) or Cmd+Shift+R (Mac)

Expected result: the page reloads and the restart loop stops. If it continues, move to the next step.

1. Use a private/incognito window to rule out extensions and cookies.

Expected result: if the list works in private mode, a browser extension or cached state is likely causing the issue.

1. Clear browser cache and storage for the site.

Browser: Settings → Privacy and security → Clear browsing data → Cached images and files; Cookies and other site data (site-specific recommended)

Expected result: cached scripts replaced; if the problem stops, corrupted cache was likely to blame. If not, continue.

1. Test in another modern browser (Edge, Chrome, Firefox) or the Lists mobile/desktop app and update the app/browser to the latest version.

Expected result: if the issue is client-specific, it will not reproduce in the other browser or the up-to-date app.

Use the official Microsoft Lists app or the SharePoint-hosted list page to compare behavior; Teams embeds can add another layer.

1. If using Teams, open the list in the browser (Open in SharePoint or Open in browser) and test there.

Expected result: if the list is stable in the browser but unstable in Teams, the Teams client or its policies may be involved.

When a client fix did not work

• If multiple browsers and devices show the same restarts, the problem is likely server-side, tenant configuration, or list-level customization.

Is the Microsoft service or my tenant to blame?

Before you start (applicability)

• Product scope: Microsoft Lists accessed via SharePoint/Teams or the Microsoft Lists app (web, Teams embed, mobile, desktop).
• Versions: applies to the modern Lists experience in SharePoint and Lists in Teams. (The exact client version varies by browser and Teams build.)
• Privileges: Tenant administrator or admin with access to the Microsoft 365 admin center is required for service health and Message Center checks; list owner or SharePoint admin is required for list-level tenant settings.
• Restart/backup: no tenant restart or backup is required for these checks.
• Safe checks to run first: check Service health and Message Center, and ask another admin or test account to reproduce while you watch service notifications.

Checks to perform

1. Check Microsoft 365 Service health for ongoing incidents that mention SharePoint, Lists, or Teams. Use the admin center Service health page.
2. Review Message Center for any recent tenant-level changes, updates, or feature rollouts that coincide with the start time of the problem.
3. Verify recent tenant configuration changes: conditional access policies, session controls, or network policy changes that could affect client scripts or authentication.
4. Verify SharePoint tenant settings that affect lists: custom script settings, modern experience toggles or any throttling/limits reported from the tenant.

Expected findings and implications

• Service incident found: wait for Microsoft updates and follow mitigation guidance in the Service health message.
• Recent tenant policy change found: roll back or test with a user excluded from the policy to confirm.
• No service or tenant change found: proceed to list-level checks and diagnostics.

Service health can show transient errors that match the timing of repeated list reloads; document times and affected accounts to match Microsoft incident timelines.

Are customizations, formatting or Power Automate flows causing restarts?

Where to act: list-level customizations, forms and automations. Privilege: list owner or SharePoint admin for modifications.

Isolate customizations safely

1. Create a copy of the view or a new test view with simple columns and no formatting, then open that view.

Expected result: if the test view does not restart, column formatting or view-level scripts are suspect.

1. Temporarily disable column formatting and custom row formatting.

List settings → Columns → (open column) → remove JSON formatting

Expected result: list loads without restarts if formatting caused client-side errors. If restarts continue, reapply formatting later or inspect the JSON.

1. Temporarily switch the list form to the default SharePoint form if a Power Apps custom form is used.

Integrate → Power Apps → Customize forms → Restore default form

Restoring the default form will remove the custom form for users. Export or save the custom form first if you need to preserve it.

Expected result: if the form caused the restart, the default form should open normally. If it stops the behavior, examine the Power Apps form for unsupported controls or scripts.

1. Disable or turn off Power Automate flows that trigger on list item create/update while testing.

Power Automate → My flows → locate flow → Turn off

Expected result: if a flow’s response causes client-side activity or repeated API calls, disabling it should stop the restarts.

1. Check third-party integrations or webhooks and temporarily disable them.

What to do if formatting JSON or flows are the culprit

• Validate column formatting JSON using Microsoft’s sample schemas or a JSON linter. Remove or simplify complex expressions.
• For Power Automate flows, add scope-limited triggers and add logging actions to identify failures.

If you cannot reproduce after disabling customizations

• Re-enable items one at a time to find the exact change that reintroduces the restart. This narrows the root cause without deleting assets.

How to collect diagnostic logs and evidence for IT or Microsoft support

Collecting good evidence speeds troubleshooting and support responses.

Browser DevTools (quick capture)

1. Reproduce the issue while DevTools is open to capture network/console errors.

Open DevTools: F12 or Ctrl+Shift+I, then select Console and Network tabs

1. In Network, click Preserve log and reproduce the restart; save the HAR file.

Network → (check) Preserve log → reproduce → right-click → Save all as HAR with content

Expected output: HAR file and console error messages showing failing network requests or script errors.

What to collect from DevTools

• Console error text and stack traces.
• Network requests that return non-200 responses or long-running requests.
• HAR file for upload to support.

SharePoint ULS and admin logs (for tenant admins)

1. If you administer SharePoint or have access to diagnostic logs via the Microsoft 365 admin tools, collect ULS or diagnostic correlation IDs shown in error details.

When an error displays an X-Correlation-ID or correlation id: copy that id and the timestamp

Expected result: correlation ID and timestamps to correlate server logs with client-side errors.

What to send to support

• A clear reproduction sequence, timestamps, and affected user accounts.
• HAR file from DevTools and screenshots of console errors.
• Correlation IDs and any ULS entries if available.
• Note whether the problem occurs in Teams, web, or mobile and which views reproduce it.

Do not include sensitive tokens or full auth headers when sharing logs; redact cookie or header values if needed.

How to verify the fix and prevent it happening again

Verification steps

1. Confirm the affected user can open and interact with the list without restarts from their primary browser.
2. Confirm multiple users and devices (including one excluded from policies) can access the list and perform the previously failing actions.
3. Monitor for the issue for a full business cycle or use the Service health page to watch for related incidents.

Expected verification output

• No reloads or console errors during the same actions that previously triggered restarts.
• HAR and console output show successful 200 responses and no repeated script exceptions.

Prevention tips

• Version control for list customizations: store JSON formatting and Power Apps forms in source control or a documented backup before changes.
• Gradual rollouts: apply formatting, forms, or flows to a subset of users first, then expand after validation.
• Routine audits: periodically review flows, webhooks, and heavy calculated columns. Remove or refactor rules that trigger frequently.
• Keep clients updated: maintain browser and Teams client versions on a regular update schedule to reduce compatibility issues.

What to do if it recurs

1. Reproduce and collect the same diagnostic artifacts and open a Microsoft support ticket with HAR, correlation IDs, and affected account details.

Conclusion

If a client-side fix (cache clear, different browser, disable extension) stops the restarts, return users to normal and then isolate the offending customization. If restarts persist across clients, collect HAR files, correlation IDs and tenant change history and escalate to Microsoft support with that evidence. While you wait, disable suspect formatting, custom forms or flows and use a simple test view to keep users productive.

Frequently Asked Questions

Can conditional access policies cause Lists to reload repeatedly?

Yes. Conditional access that forces reauthentication or blocks certain resources can interrupt client requests and cause repeated reloads for affected sessions. Test by excluding a user from the policy temporarily or reviewing sign-in logs for related failures.

Is it safe to disable flows and custom forms while troubleshooting?

Yes, temporarily turning off flows or switching to the default form is a safe way to isolate the issue, but export or document the existing customization first because changing or removing a custom form can affect users if you don’t restore it.

What if DevTools shows only generic network timeouts?

Network timeouts can indicate service degradation, throttling, or client network problems. Correlate with Service health, check network paths or proxies, and collect HAR and timestamps before escalating.