
What GoHighLevel Can And Cannot Do, Measured
Every limit worth knowing on this platform returns 200 OK and carries on.
Systems Ninjas (2026). Measured capabilities and silent failure modes of a leading marketing platform. Every finding measured against live accounts between 2026-06 and 2026-09. systemsninjas.com/post/gohighlevel-limits-measured
Take any of it. You do not need to ask. If you find an error in here we would rather hear about it than not, and the correction goes on the page.
It can replace more of the software a small business runs on than its critics think. And it fails in a more dangerous way than its fans admit.
The danger is not the features it lacks. The danger is that most of its real limits look like success. You ask it to do something. It answers 200 OK, which is what a computer says when it means "done, no problem". Then it carries on as though the thing you asked for happened.
It did not happen.
We build on it every day. This is the list we wish someone had handed us at the start. Every item on it is something we tested ourselves. None of it came out of a manual.
01 / The patternThe one pattern behind all of it
Most software fails loudly. You ask it to do something it cannot do. It shows you an error. You fix it and move on.
Several of the things that matter most on this platform do the opposite.
You ask. It says yes. It tells you the change is saved. The version number even ticks up by one, the way a saved document shows you it now has a newer draft. And nothing has changed.
If you take one thing from this page, take this. On this platform, go and look at the thing your customer looks at, and read the answer off that.
Not off the reply the system sent you. Not off the preview inside the page editor. Off the live page, the live record, the live bill.
02 / The silent onesThe quiet failures, worst first
1. Once a blog post is published, you cannot change the words inside it. You send the new text over. The platform takes it, reports success, gives the post a new version number, and moves the "last updated" date forward. Then it keeps the old words. It goes one step further. The reply it hands back to you contains the OLD text, not the new text you just sent. So the reply cannot warn you either. Changing one sentence in a published article costs you all of this. Move the old post to a different web address. Build a fresh post at the real address. Then hand the search engines an updated map of your site. For the seconds in between, the real address shows a 404, the "page not found" screen that visitors and search engines both land on.
What that means day to day: on this platform, write the article as if you are carving it into stone, because that is what you are doing. A mistake you spot before you publish costs nothing. A mistake you spot afterwards costs everything in the paragraph above.
2. You cannot delete a blog post. The only way to take one down is to file it away, and filing it away leaves traces behind. Once you press publish, treat it as close to permanent.
3. One switch on the payment page reads as "make every item compulsory". What it actually does is charge for the first item and nothing else. Turn off the setting that lets a buyer pick and choose between items, and both items still appear on the page. The tick boxes beside them vanish, which is exactly what you were trying to do. And the total quietly adds up the first item alone. So your customer reads a line that says "$100 per month". They are never charged that. No monthly payment is ever set up.
It looks right on the screen. It is the most dangerous setting on that whole payment page. It was live on our own website before we caught it.
4. A one-off setup fee is charged, and nothing on the page says what it is. A monthly price can carry a setup fee on top of it. The payment page adds that fee into the total correctly. But the sentence that explains what the extra money is for lives in a different part of the system, and the payment page never prints it. So your buyer sees "$100 per month", then a total of $600, and nothing anywhere on the page explaining the other $500. Either write that sentence yourself, or take the two payments separately.
5. Change a product and the live page carries on selling the old one until you publish that page again.
The page editor cannot warn you about this, because it never shows you your real products at all. It shows a stand-in item at a stand-in price, whatever you have actually set up. So the one screen where you would expect to catch the mistake is the one screen that cannot show it to you.
6. Tell the calendar you are open at the weekend and it agrees, then ignores you. You add both weekend days to your opening hours. The calendar accepts them and saves them. Ask it later what your opening hours are and it reads both days back to you correctly. Then it offers your customers no times at all on those days. Weekdays behave normally. Your settings look right on every screen and your weekend is empty.
7. A brand new order form links its terms and conditions to example.com. That is a stand-in address, the way "Your Name Here" on a printed form is a stand-in name. Switch on the terms tick box and leave those links alone, and you have put a live payment page in front of real customers that sends them to a website that is not yours.
8. Your blog is a separate website as far as any code is concerned. None of the code sitting on your main site carries across to it. So the blog goes live with no cookie banner, and with no links to your privacy or terms pages, unless you paste that code in a second time by hand. Nothing warns you. The blog looks fine, because a page missing a cookie banner looks exactly like a page that never needed one.
03 / The other directionThree things people think it cannot do, and it can
Three corrections that run the other way. A page about limits that lists nothing but limits is not an honest page. It is a rival's sales pitch.
Your calendar settings control the booking page the public sees. They do not control your own staff.
Appointment lengths, the gaps between them, the padding either side and your opening hours all shape what a VISITOR is offered. They put no limit whatsoever on a booking made by your own team inside the system, or made by another piece of software talking to it through the API. The API is the doorway one program uses to reach another. We tested it. On a calendar set to 50-minute appointments we booked a 90-minute one and a 25-minute one. On a calendar set to start appointments every 15 minutes we booked one starting at 08:07. We booked at 22:00, outside opening hours. We booked on a day the calendar was shut. We put two people in the same slot on purpose. We made appointments that were nothing but free text, with no service attached to them at all. Every single one went through.
That is the whole difference between "this platform cannot replace their booking system" and "it replaces it exactly".
Think of a restaurant. The online booking page will only offer you a table on the hour. The person answering the phone writes you in at half past, because they can see there is a table free. This platform behaves the same way. The rules bind the booking page, not the person. Any business whose front desk writes bookings in by hand works like this. For them, the calendar settings barely matter. So find out how a business really takes its bookings before you design anything around those settings.
You can build your own record types and your own dashboards on every plan. The platform calls a record type you invent yourself a custom object. It is a new kind of card in the filing cabinet, for something the software ships with no box for: a vehicle, a property, a course.
Both of these used to sit on the expensive plans. Neither does now. So nobody needs to pay more to get them, and nobody should be bending ordinary contact fields into knots to fake them. One limit is worth knowing before you build on it. You get 10 custom objects per account, and no more. That is plenty for most businesses. It is not plenty for a few. Better to learn that here than three objects into designing your system.
Every step inside an automation can be read out in full.
The obvious way to ask for a list of automations gives you names and dates and nothing else. It cannot tell you whether an automation holds a hundred steps or none. An empty one and a full one come back looking identical, which is where most tools built on top of this platform go wrong. The whole thing is readable another way. Every step, whatever sets the automation running, and every condition inside it, all of it, through the platform's own inner workings. That is how we go through a client's automations without ever asking anyone to send us a screenshot of one.
04 / Where it stopsWhere it really does stop
A short list, because these three are built into the platform. They are not mistakes that somebody will fix.
- There is no permission setting for what the bot knows. A permission is one line on a list saying what a login is allowed to touch. For the bot's knowledge, that line does not exist anywhere. So you cannot let a client edit what their bot knows without handing them the bot itself. The only way round it is to keep that knowledge in a document the client owns, and have the platform read from it.
- Some bots cannot be tied to one named AI model at all. Depending on how the bot was built, the platform flatly refuses to accept the setting. So if the vendor swaps the AI brain inside that bot for a different one, it changes underneath you. Nobody has a switch to stop it. Not you, not your agency, not anyone.
- The blog section itself has to be set up by hand. No other software can create it for you. One manual step, every time.
05 / If you are buyingWhat this means if you are buying
Three things follow from all of this. Only the third one is about the platform itself.
- Ask any agency what they VERIFY, not what they build. To verify something is to go back afterwards and check that it really happened. On a platform whose favourite way of failing is to tell you everything went fine, "we tested it" has to mean "we went and read it back off the live page". Those are two different sentences. It is worth making someone say the second one out loud.
- Assume your payment page is wrong until real money has gone through it. Put your own card through your own order form before you send a single customer to it. It costs you the price of your cheapest product.
- The platform is not the risk. Work that nobody checked is the risk. We are not warning you away from it. We build on it by choice, every day. But an agency that has never run into the list above has not been looking hard enough. Every item on that list costs money quietly. Not one of them throws an error to tell you.
We measured every finding above ourselves, on live accounts, between 2026-06 and 2026-09. The vendor releases changes every week, and any of these could be fixed without anyone announcing it. If one of them has been fixed, tell us. We will correct this page and put the date of the correction on it.
Send us the one thing you were told it cannot do
Half the limits people are quoted are real and half are somebody's workaround from three years ago. Tell us what you were told, and we will go and test it against a live account and send you what actually happened. No charge, and if it turns out the platform genuinely cannot do it, we will say so plainly.
Send us the claim [email protected] · No client of ours is named anywhere on this page, and if you become one, you will not be either.