Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Sourcetree 2.7 (144): High CPU load on Mac OS High Sierra 10.13.2

I recently updated to Sourcetree 2.7 (144) and I've noticed very high CPU load when operating on a Bitbucket HTTPS git repo - just typical commits and pushes.

It first came to my attention when I noticed the fan on my Mac OS High Sierra 10.13.2 machine was blasting after using Sourcetree for just a while. The CPU load in Activity Monitor showed >150%.

Even when it was idle, the CPU load would drift between 60-150%.

The machine specs are MacBook Pro, 2.8 GHz Core i7, 16 GB RAM, 185GB of free disk space on a 1TB SSD.


43 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

For the love of god please fix this. 

Yeah this is driving me mad. My usually good battery was dead within 2 hours of me arriving at a conference because I forgot to kill sourcetree. Its #1 on 'Significant battery usage'. 

When its running (and not even in use) fans are going full speed and CPU spikes. 

Like # people like this

Seriously! SourceTree has been practically unusable for over 6 months now.

Like Achim Köllner likes this

I highly recommend checking out Tower 3. This issue forced me away from SourceTree and I highly doubt it's getting fixed anytime soon.

Like Achim Köllner likes this

I removed the version 2.7 of SourceTree and downgrade to 2.5.3. This version works also with high sierra

I've downgraded to 2.6.3 (134) and it is working for me on High Sierra 10.13.2.

This was a great suggestion - works for me as well.

2.6.3(134) works fine too on Mac OS Sierra 10.12.6

LOL, the sneaky bastard updated itself to the crappy 2.7 version again (after a restart) and I only noticed by after I got annoyed by tie the sound of the vent blasting away continuously ...

Thanks for the archive link! I'm also having issues since 2.7, not cool at all! Downgrading asap.

I've loved SourceTree for a long time, but this issue provided an opportunity to check out the upcoming Tower 3, and I have to be honest, I'm not sure I'll come back to SourceTree even if Atlassian ever decides to take this seriously and fix it. The new Tower is a pure joy to use. SourceTree could stand to take some cues.

8 votes
bgannin Atlassian Team Jul 17, 2018

Hi everyone,

I've identified a [the?] primary source of spins for our next major update, which just started internal alphas. The overall issue of performance is definitely not being ignored; it's challenging for our small team to balance responding to everyone and providing details while debugging reports and doing feature development. We appreciate your patience and enthusiasm and are working hard to this resolve pain point.

Brian Ganninger
Senior Mac Developer, Sourcetree

Thanks, Brian. It seems to me that performance should be your primary concern. I'm now trialing Tower because of this - which is a shame because I think the SourceTree UI is great.

If you could keep us up to date with progress then I think you'll keep us all.

Thanks again.

Hi @bgannin. If you guys are short in resources, you could just go open source and this kind of stuff would get solved in 1 day.

I know you might not be the decision maker here, but you have more influence than me for sure.

@bgannin I'm so glad that this issue is not being ignored - my team has been stranded on 2.6.3 for months.  Can you tell us what version this fix will land in so that I can try it when it is released?  2.8? 3.0?

Hi @bgannin,

Thanks for the good news... is there a ticket where we can watch progress? Mobile team and battery life is at stake for us.

@bgannin I thought I would give the 3.0 Beta a try (196) and I see sustained high cpu use still, but it is less than it used to be.  It was 90% now it is 35%, but I also got a significantly more powerful MacBook pro, so I don't know if the software or hardware is to blame for the improvement.  At any rate, sourcetree continues to be the main battery drain on my laptop.

Do you have any more updates you can provide?

bgannin Atlassian Team Sep 26, 2018

There are improvements specifically for this in 3.0. Additional ones are planned for 3.0.1. A more substantial change that requires rearchitecting portions of Sourcetree is roadmapped but does not have an ETA.

@bgannin Correction, the Sourcetree-Beta is still using 100%-110% in the background.

@bganninThis is insane. Your product has been unusable on Mac for almost a year now. Why even bother allowing people to download it? Why pretend that it works?

How many newbie users are running your software and thinking they need to buy a new computer? It's just unethical at this point. Your software is critically flawed on Mac - you should at least tell Mac users it's broken before you allow them to use it.

Like tk-iddy likes this

@bgannin Why is 2.6.3 not affected?

Like tk-iddy likes this

I've been noticing SourceTree causing slowness on my Mac too.

SourceTree: 2.7 (144)

OS: OSX Sierra (10.12.6)

Processor: 2Ghz Intel Core i7

Memory: 16GB 1333 Mhz DDR3

Screen Shot 2018-01-01 at 5.47.42 PM.png

Same here, %CPU always between 80 and 100%, decreasing battery life significantly. Restart doesn't help, I have to keep Sourcetree turned off.

Screen Shot 2018-07-10 at 16.52.32.pngIt uses more power than Chrome and PhpStorm combined! 

Well this is a depressing #metoo

Screenshot 2018-03-29 21.20.59.png

Fix this please - it's killing my MBP!

This appears to still be the case on 2.7 build 152, High Sierra. Unlike the initial poster, I see the symptom with SSH repositories present, so it is not specific to HTTPS. It wastes approximately 100% of one CPU all the time while running, idle. Ample disk, ample RAM, a couple of versions back there is no such problem, so I don't think there is anything about the machine causing this problem, but rather only a defect in the current source tree. This is... not ideal.

Unfortunately the only workaround I've found for this is to use a different Git tool when operating on battery.

It'd be great if Atlassian could provide an update to this issue. 

I prodded them on Twitter: response was "Regarding the high CPU usage, our team is aware of the issue and continuing to investigate solutions. Thanks for reaching out!" (as of March 12th). 

That doesn't convince me they're active on this. 

 I am also experiencing this and cannot figure out how to fix it. Cannot use ST because CPU runs at 90-100% and never goes bellow. On paid bitbucket account too. 

Well, I simply can’t afford to use Sourcetree in this state. So after about 5 years of happiness, it’s Good bye Sourcetree, hello Tower.

2 votes
bgannin Atlassian Team Dec 11, 2017

We've had a couple reports about this and will investigate shortly. Thanks for the info.

Brian Ganninger
Senior Mac Developer, Sourcetree

Also experiencing this, but only when the interface is visible. If Sourcetree is running, but no windows are open, then it will eventually lower it's CPU usage. But open the main window, and back up to between 100% and 130%.

Screen Shot 2018-01-04 at 15.37.23.png

This is still happening with the latest build (152).

Build 150 fixed it for me. 152 also still good on my side.

I've installed build 152 - and while it seems a bit better, there is still what seems like a high idle CPU around 60%. Additionally, I noticed spindump firing up after running SourceTree. The log file indicated a high rate of idle wakeups:


Date/Time:       2018-01-12 14:22:36.973266 -0500

OS Version:      Mac OS X 10.13.2 (Build 17C205)

Architecture:    x86_64

Report Version:  19


Command:         Sourcetree

Path:            /Applications/

Version:         2.7 (152)

Parent:          launchd [1]

PID:             6935


Event:           wakeups

Wakeups:         45001 wakeups over the last 6 seconds (7027 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds

Action taken:    none

Duration:        6.40s

Steps:           3


Hardware model:  MacBookPro11,5

Active cpus:     8


Fan speed:       3539 rpm



Powerstats for:  Sourcetree [6935]

UUID:            BDA3F21B-4C84-312A-93C9-F5FAD260A32E

Start time:      2018-01-12 14:22:40 -0500

End time:        2018-01-12 14:22:42 -0500

Microstackshots: 3 samples (100%)

Primary state:   1 samples Frontmost App, Kernel mode, Effective Thread QoS User Interactive, Requested Thread QoS User Interactive, Override Thread QoS Unspecified

User Activity:   0 samples Idle, 3 samples Active

Power Source:    0 samples on Battery, 3 samples on AC

  2 NSApplicationMain + 804 (AppKit) [0x7fff54ee0f1a]

    2 -[NSApplication run] + 764 (AppKit) [0x7fff54f11d6d]

      2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 (AppKit) [0x7fff556b2b4c]

        2 _DPSNextEvent + 2085 (AppKit) [0x7fff54f1cf5f]

          2 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox) [0x7fff56c51914]

            2 ReceiveNextEventCommon + 613 (HIToolbox) [0x7fff56c51b96]

              2 RunCurrentEventLoopInMode + 286 (HIToolbox) [0x7fff56c51e26]

                2 CFRunLoopRunSpecific + 483 (CoreFoundation) [0x7fff57939d23]

                  1 __CFRunLoopRun + 1654 (CoreFoundation) [0x7fff5793a626]

                    1 _kernelrpc_mach_port_insert_member_trap + 10 (libsystem_kernel.dylib) [0x7fff7f37f762]

                  1 __CFRunLoopRun + 2427 (CoreFoundation) [0x7fff5793a92b]

                    1 __CFRunLoopDoTimers + 346 (CoreFoundation) [0x7fff5794332a]

                      1 __CFRunLoopDoTimer + 1822 (CoreFoundation) [0x7fff57943afe]

                        1 __CFRepositionTimerInMode + 135 (CoreFoundation) [0x7fff5790e1b7]

                          1 __CFArmNextTimerInMode + 621 (CoreFoundation) [0x7fff5790e66d]

                            1 <User mode>

  1 _pthread_wqthread + 1387 (libsystem_pthread.dylib) [0x7fff7f4c41ca]

    1 _dispatch_worker_thread3 + 101 (libdispatch.dylib) [0x7fff7f2016ed]

      1 _dispatch_root_queue_drain + 515 (libdispatch.dylib) [0x7fff7f201941]

        1 _dispatch_source_invoke + 620 (libdispatch.dylib) [0x7fff7f202018]

          1 _dispatch_continuation_pop + 472 (libdispatch.dylib) [0x7fff7f212e76]

            1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff7f1ffd50]

              1 ??? (Sourcetree + 2746683) [0x102eb693b]

                1 ??? (Sourcetree + 2747263) [0x102eb6b7f]

                  1 ??? (Sourcetree + 2747605) [0x102eb6cd5]

                    1 ??? (Sourcetree + 732931) [0x102ccaf03]

                      1 ??? (Sourcetree + 731468) [0x102cca94c]

                        1 ??? (Sourcetree + 729390) [0x102cca12e]

                          1 ??? (Sourcetree + 1590826) [0x102d9c62a]

                            1 ??? (Sourcetree + 1590312) [0x102d9c428]

                              1 ??? (Sourcetree + 1589609) [0x102d9c169]

                                1 ??? (Sourcetree + 1588912) [0x102d9beb0]

                                  1 <User mode, Effective Thread QoS Default, Requested Thread QoS Default>


  Binary Images:

         0x102c18000 -        0x102fb3fff  com.torusknot.SourceTreeNotMAS 2.7 (152) <BDA3F21B-4C84-312A-93C9-F5FAD260A32E> /Applications/

      0x7fff54edb000 -     0x7fff55d38fff 6.9 (1561.20.106) <7A71ACCF-2DF5-3557-BB22-3A9FC9F71CCF> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

      0x7fff56c22000 -     0x7fff56f27ff7 2.1.1 <ADBE7A1B-0402-369C-A6F3-494E8CACD619> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox

      0x7fff578b5000 -     0x7fff57d55fff 6.9 (1450.16) <23F8373A-FA3F-37A2-BA5B-70061BFCCD21> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

      0x7fff7f1fe000 -     0x7fff7f237ff7  libdispatch.dylib (913.30.4) <7D0E3183-282B-3FEE-A734-2C0ADC092084> /usr/lib/system/libdispatch.dylib

      0x7fff7f36d000 -     0x7fff7f392ff7  libsystem_kernel.dylib (4570.31.3) <D2E842AA-3B8D-31BF-8234-8C1BE11CFE32> /usr/lib/system/libsystem_kernel.dylib

      0x7fff7f4c1000 -     0x7fff7f4ccfff  libsystem_pthread.dylib (301.30.1) <ABA848E1-6978-3B42-A3A7-608B2C36FA93> /usr/lib/system/libsystem_pthread.dylib

Still happening to me in build 152 after upgrading from mac OS Sierra to High Sierra.

I spoke too soon. 152 still has this problem.

Hi @bgannin I'm also experiencing this problem on build 152. The last few days I've noticed my CPU even sitting as high as 100%. As far as I can tell from using Activity Monitor's "Sample Process" tool, it's all in the NS drawing API, and primarily occurs when I have a repository workspace window open (not just the repo browser). And restarting SourceTree only brings it down from 100% to nearer 30-40%.

It's been almost 2 months since your above message. Can you please provide an update? This issue makes it tough to work without being plugged into the wall outlet, since it drains the battery.

Now that we've wrapped up 2.7 and 2.7.1 we're able to dedicate the next release focused solely on performance and reliability across the board.

Thanks for the update - I look forward to the upcoming releases.

V 158 still with the issue


I noticed that the issue that appears to be tracking this problem (or at least a similar one) is prioritized as "low":

An issue closed as a duplicate was marked as "highest":

The severity rating is similarly downgraded from "major" to "minor".

Any chance this slipped under the PM radar and should have been re-prioritized higher? Or, if there's a different ticket open for this, could you advise on the issue number?

bgannin Atlassian Team Mar 16, 2018

The tickets are a bit out of sync… the morale of the story is we're currently working on it for the next update.

Still happening on 2.7.2 (168) - Is anyone really working on this? The program (as nice as it may be) as such is barely usable right now.

Hi @bgannin - I installed and launched 2.7.3 (169) filled with hope that this would be resolved. It seemed at first to be keeping a low CPU usage, and it did if I only used the Repository Browser window. But within moments of opening any repository's window it crept back to 100% and hovered there.

I like this app. I like that my team uses the same tool. I want to see this fixed.

Let's talk. Where's your research led so far?

Here's what I've found:

  • Closing all windows, and reopening the app with only the Repository Browser window open leads to normal, very low CPU usage
  • Working within a very tiny repository (i.e. 2 commits, 8 files) CPU usage will peak briefly/periodically around 10-15% and then drop to very low usage.
  • Working within a very large repository (i.e. hundreds of commits, thousands of files) CPU generally usage stays at 100%
    • Opening this window initially, not clicking on anything, and switching immediately to the Mac Activity Monitor, the CPU actually hovers around 50% for around a minute, then drops to very low usage.
    • Clicking back to this window and then back to Activity Monitor immediately SourceTree jumps to 100% CPU for 1-2 minutes, then drops to very low usage. Periodically spiking to 100% again even while in the background.
    • Once I start navigating around between views (File Status, History, various branches), it never seems to drop back below 100% usage, even if I focus on another application for a while. I suspect this is where most of the other users' reports are coming from, as it's pretty normal usage. It simply appears to be always at 100% usage.
    • Once the 100% CPU has started, closing the large repository's window, so that only the Repository Browser is open, does not stop the CPU load for a couple minutes. But once it does stop, it seems to act closer to when the app was launched with just the Repository Browser, but hovering periodically around 75% usage. This leads me to believe this is possibly a leaky object reference tied to a long-running refresh or redraw operation.

Tangentially, I noticed a while back that there was a sort of automatic filesystem refresh that was added. Before that, I believe it would refresh when I returned from another application, or when I manually requested it. Now it seems to do so even in the middle of reading through a diff (which can be somewhat annoying, but I digress). I mention it in case it's related. The brief spike I noticed in the tiny repository - if related to the longer spike in a large repository - could be caused by the same code. I'm picturing a possible cascade of collection or visual updates triggered from the filesystem refresh, that never quite finishes before the next auto-refresh is started.

Using the Mac Activity Monitor and the "Sample Process" utility on Sourcetree, it appears all the samples fall in NS and CoreFoundation calls from, for example, mach_msg_trap. I'm not an expert in the Mach kernel, so I can't add any further insight here. But I figured it was worth mentioning along with the observations above.

Lastly, are there any other suggestions you have to eliminate the CPU issue? Do we need to reinstall, clear a cache, upgrade git, downgrade, or anything else that you've tried that helped?


This is still an issue.

21 june, still 110 - 150% of CPU loading. Macbook always using fan, always hot, thanks for your soft. WTF? 

How can this still be an issue? It was said to be investigated and a prioritized part of the upcoming releases over six months ago? 


Ive downgraded to 2.6.3 to solve this, there seems to be pretty little hope even for a timeline when this could be solved. Im starting to look into switching to Tower...

Hey, as a hint for @bgannin, who may or may not even be paying attention, I learned that the CPU doesn't spike while the little gear menu in the top-right of the main bookmarks listing window is open. Opening that menu causes SourceTree to immediately drop down to typical idle CPU usage levels, and closing it makes SourceTree immediately spike back up to 100%.

Like # people like this

Also noticed about high CPU usage. To fix this temporary need restart sourcetree.

Process `/usr/libexec/nsurlstoraged` taking too many cpu time, after that Source tree may crash.

I have the same problem. Over 100% CPU Time. I have to Kill the Process all the time. Version 2.7 (152). MAC OS X El Capital 2.5 GHz Intel Core i7, 16GB DDR3

I have the same issue on my Mac OS X El Capitan / 10.11.4, with SourceTree 2.7(152). I've downgraded to 2.6.3(134) and the cpu usage drops back down. 

Me too! It gets to the point that I'm looking for alternative.... Tired of high CPU.

Thanks for doing nothing about it.

Happening still on

- macOS 10.13.3 (17D47),  MBP 15" Retina 2015, 2.7GHz 16G RAM 

- with SourceTree 2.7.1 (159) git-embedded 2.5.1 git-lfs 2.3.4 

CPU usage for SourceTree process won't go under 40%, with just 1 repo window open, git+ssh from

I tried system git (2.6) and different other repositories. Waited for 15min to "chill down", but still no less than 40% CPU. Laptop fan is blasting continuously...


I can't use the app anymore. I'll do the archive-download of an older version ...

Too bad, it was such a great app about 1 year ago, when it wasn't probably bloated with all the new fancy (useless?) features :-(

Same issue, CPU > 100% most of the time the program is running. 

I think I'll bail on SourceTree until this gets resolved. It's killing my laptop battery life. Ping me if it gets fixed. 

I got sick of waiting & switched to GitKraken.

Experiencing extreme slowness along with the high CPU usage, switched to GitKraken. Sucks, I like SourceTree better, but it's literally unusable.

I switched back to 2.6.3 and it works perfectly. I even like it more as the commit list is more compact (less line height) so more history is viewable on the screen at the same time. Deactivated the auto-update.

Same here! CPU is killing it. When on battery it drains new macbook in an hour. Even with just one repo open.

Same issue here. SourceTree v2.7.1 on High Sierra v10.13.3. Never drops below 90% CPU. 


This is making Sourcetree basically unusable on OS X. Would love an update on this issue.  

Currently, you'll want to downgrade to 2.6.3 -

@Scott Colestock Dear Scott, Do you know the version number for the stable Windows SourcetTree? Thanks to your indication, I downloaded the 2.6.3 version for Mac and it is great. Now, I would like to know the one that I should download for Windows. Thanks

See the low priority bug on the SourceTree JIRA - I don't think Atlassian are taking this seriously enough.

Yeah also seeing this - please fix 

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

Community showcase
Published in Sourcetree

Tip from the team: configure your repos for hosting goodness!

Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...

3,850 views 4 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you