Table of Contents
Sonar Feels Slow: What to Check First
Updated
by Jennifer Trower
Read Time: 7 mins
A slow instance is frustrating, and the cause is not always obvious. Sometimes the slowdown is happening across the whole platform, sometimes it is your browser or local network, and sometimes it is specific to your instance. Each of those points to a different next step.
This article gives you a short set of checks to run in order. Most slowdowns are resolved by one of the first few steps, and the rest of the article tells you exactly what to gather and when to send it to support so the issue can be looked into without delay.
Start Here: Run These Checks in Order
Work through the steps below from the top. Each one takes a minute or two, and you can stop as soon as the slowdown clears. If you reach the end and Sonar is still slow, the final section tells you what to send to support.
Step 1: Try a few quick checks on your side
Use these first, because they are the fastest to rule in or out and they resolve a large share of slowdowns. Try them in order and re-check Sonar after each one:
- Refresh the page. A single hard refresh often clears a one-off hang. On Windows use Ctrl + Shift + R, and on Mac use Cmd + Shift + R.
- Clear your browser cache, then close and reopen the browser. A stale cache is one of the most common causes of pages loading slowly or displaying old data.
- Open Sonar in a private or incognito window. A private window runs without your extensions and with a clean cache, so if Sonar is fast there, the cause is something in your normal browser profile.
- Disable browser extensions, especially script blockers and privacy extensions. Script blockers such as uBlock Origin and NoScript, and the privacy features built into browsers like Brave, can block parts of Sonar from loading.
- Try a different supported browser. If Sonar is fast in another browser, the issue is isolated to your original browser.
Step 2: Rule out your network and device
Sonar runs in your browser and depends on your connection to reach it. Before assuming the slowdown is in Sonar, confirm the basics on your side:
- Check whether other websites and cloud tools are also slow right now. If everything is slow, the cause is likely your local network rather than Sonar.
- Run a quick internet speed test, and if you are on Wi-Fi, try a wired connection or move closer to the access point.
- Confirm your computer is not under heavy load from another program. A browser or background app consuming most of your CPU or memory will make every site feel slow, including Sonar.
Step 3: Check the Sonar status page
If the quick checks did not help, the next step is to find out whether the slowdown is happening on the Sonar platform itself. The status page is the fastest way to confirm this.
Open the status page at status.sonar.software and look at the top of the page:
- All Systems Operational means there is no known platform-wide issue, so continue to the next step.
- An active incident banner means Sonar is already aware of a platform issue and is working on it. When this is the case, there is no need to open a ticket. Subscribe to the incident for updates and watch for the resolution notice.
While you are on the status page, the System Metrics section shows live HTTP response time and GraphQL API response time, and the uptime bars show the last 90 days at a glance. These give you a quick read on how the platform is performing right now.
Step 4: Narrow down where the slowness happens
If Sonar is still slow and there is no incident on the status page, gather a few details about the slowdown. The more specific you can be, the faster the issue can be diagnosed.
- Is the whole instance slow, or only one area, such as a specific report, the transactions tab on an account, or a particular list view?
- Is it slow all the time, or only at certain times of day or during certain actions?
- When did it start, and did anything change around then on your side, such as a new device, a new network, or a new browser?
- Does it affect everyone on your team, or only you? If only you, Steps 1 and 2 are the most likely cause.
If the slowdown is limited to reporting, the cause and the fix are often different from a general slowdown, since reporting runs on separate infrastructure.
Quick Reference: What the Symptom Usually Points To
Use this table to match what you are seeing with the most likely cause and your next step.
| What you are seeing | Most likely cause | What to do next |
| Everyone reports Sonar is slow at the same time | A platform-wide issue | Check the status page. If there is an incident, subscribe and wait. |
| Only you are slow; a private window or another browser is fast | Your browser, an extension, or a stale cache | Clear cache and disable extensions (Step 1). |
| Every website is slow, not just Sonar | Your local network or device | Run a speed test and check your connection (Step 2). |
| Only reporting is slow or will not load | Reporting-specific behavior | Note which report, then see the reporting note above and contact support if it persists. |
| One specific page or action is slow, consistently | Possibly instance-specific | Gather details (Step 4) and contact support with a current HAR file. |
| Gateway errors, 502 or 504, or pages timing out | Often a platform issue | Check the status page first, then contact support if nothing is posted. |
When to Contact Support and When to Wait
Knowing which of these applies will save you time and help the issue get resolved faster.
When to wait
- There is an active incident on the status page. Subscribe to it for updates. There is no need to reach out, since the team is already engaged.
- The slowdown cleared after a quick check in Step 1 or Step 2. If it was a stale cache, an extension, or your local network, there is nothing further to report.
When to contact support
Reach out to support when the slowdown is still happening, there is no incident posted on the status page, and the quick checks did not resolve it. This is especially worth doing when the slowdown is limited to a specific instance, area, or action and you can reproduce it.
What to Include When You Contact Support
To look into an instance-specific slowdown, support needs to see what your browser is experiencing at the moment it is slow. Having these ready when you reach out avoids a back-and-forth and gets the investigation started sooner:
- A current HAR file. A HAR file is a recording of the network activity in your browser while you reproduce the slowdown. It is the single most useful thing you can provide. It must be captured at the time the issue is happening — an older file from a previous occurrence will not reflect the current behavior and cannot be used.
- Your device and browser details. Include your browser and version, your operating system, and a rough idea of your computer's specifications.
- A clear description of the slowdown. Note what is slow, when it started, whether it is constant or intermittent, and whether it affects your whole team or only you (the details from Step 4).
It helps to know how the process works from here, so the timeline is clear:
- Support will review what you provide and work through their troubleshooting steps with you. This step comes first, and it is how the cause gets confirmed.
- If the review points to something that needs engineering attention, support creates a bug record and routes it to the right team. A bug record is not created before the troubleshooting steps are completed, so working through them with support is what moves things forward.
- Throughout, the status page remains the place to watch for any platform-wide updates.
