Nobody books a HubSpot audit because they want an audit. They book one because two systems disagree about the same number, or the forecast stopped being believable, or the bill went up and nobody can say which change caused it. The portal still works. It just quietly stopped describing the business.
The trouble is that "audit" covers two very different products. One is a person forming an opinion about your portal and writing it down. The other is a structured pass over things that can actually be counted, ending in decisions. This guide is the second kind: what to check, which numbers HubSpot already calculates for you, the limits that bite before anyone notices, and the one layer an internal review structurally cannot see. If you are earlier than this and still working out how the pieces connect, the guide to HubSpot integrations covers the landscape first.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
What Is a HubSpot Audit?
A HubSpot audit is a structured review of a portal that ends in a list of decisions. That last clause is the whole distinction. A review that ends in observations has moved the work onto you rather than done it.
There are three layers, and they are not equally hard.
The countable layer is duplicates, properties, workflow and list counts, pipeline structure, association usage and API volume. All of it is measurable, most of it is measured by HubSpot already, and none of it requires judgement to gather. This is the layer that gets sold as an audit most often, because it is the layer that looks most like work.
The process layer is whether lifecycle stages, deal stages and required fields still describe how the business actually sells. This needs conversations rather than screens, and it is where an experienced outsider genuinely earns a fee, because everyone inside has adapted to the current shape and stopped seeing it.
The boundary layer is what every connected system writes into the portal, on what schedule, under whose credentials, and whether anyone still owns those mappings. This is where the expensive findings live, and it is the layer most audits skip, because auditing it means reading the other system too.
Why HubSpot Portals Drift
It is worth being clear that drift is not a hygiene failure, because framing it that way makes people defensive and slows the fix.
Portals drift because businesses change and CRM configuration is a snapshot of a business at a moment. Someone adds a property for a campaign that ran once. A pipeline stage gets added for a deal type you no longer sell. A required field goes onto a form, and every record created before it is now incomplete by a definition that did not exist when those records were created. Ops runs a cleanup, renames a property, and three integrations that referenced the old internal name go quiet in three different ways.
None of those are mistakes. They are a business doing normal things to a system that records decisions permanently and forgets the reasoning immediately.
What makes this compounding rather than linear is that most of it is invisible at the record level. A rep looking at a contact sees a contact. They do not see that the record has fourteen properties nothing reads, that its company association was created by an integration disconnected in March, or that it counts against your marketing contact tier because it arrived through a form tool that defaults new contacts to marketing.
The Audit HubSpot Already Runs for You
Before paying anyone to count things, it is worth knowing that HubSpot counts most of them and shows you the results. Four screens carry the majority of the countable layer.
The data quality overview
Available across Marketing, Sales, Service, Data, Content and Revenue Hub at Starter, Professional and Enterprise levels, this is the closest thing HubSpot ships to an audit dashboard. It surfaces duplicate volume and the percentage change since a start date, formatting issues by object, enrichment coverage, and a property insights tab that separates properties into duplicates, "no data" and "unused". Property anomalies, meaning properties that fell outside an expected range, need Data Hub Professional or Enterprise. You can also set an alert that fires when duplicates cross a threshold you pick, checked every twenty four hours, and subscribe to a weekly digest of issue volume so the check happens without anyone remembering to run it.
Data Management, then Data Model, then the Limits tab
This is the screen almost nobody opens, and it answers the question that causes the worst surprises: how close are you to a ceiling. It tracks records per object, associations between them, custom and calculated properties, pipelines per object, association labels on Professional and Enterprise, and custom objects on Enterprise. The most useful single view here lists records that have reached eighty percent or more of their association limit, which is the earliest honest warning that an integration is over-associating records.
The audit log
Available on Starter, Professional and Enterprise, this records user-based actions and excludes automated updates like form submissions. Standard views retain thirty days, so it is a drift detector rather than an archive, though security activity exports cover the last year. Enterprise accounts can filter by additional categories including Approval, Content and Workflows, and can view an individual user's audit log. Super Admins on any paid tier can also export the last ninety days of HubSpot employee logins into the account.
Connected apps, then the connection insights tab
The single most under-used screen for anyone whose problem is actually an integration problem. The home tab flags apps with expired connections, apps that are disconnected, and apps with connection errors. The insights tab shows connection and disconnection events, reinstallations, data sync setting changes, daily record event counts by app broken into Created, Updated, Deleted and Merged, and an API call usage section for tracking daily call volume across private apps and identifying spikes.
A HubSpot Portal Audit, Step by Step
Here is the countable pass in the order that surfaces problems fastest. This is an afternoon for someone with Super Admin access.
- 1
1. Count duplicates and check the ceiling
Open the data quality overview and read the duplicate count for contacts and companies, which are the only two objects the duplicates manager handles. Then check it against your tier: Professional and Enterprise surface up to 10,000 duplicate pairs, Data Hub Professional up to 30,000 and Data Hub Enterprise up to 100,000. This matters more than the raw number, because a portal sitting at its pair ceiling is not a portal with that many duplicates, it is a portal where you cannot see how many you have.
- 2
2. Separate properties in use from properties that merely exist
Every object allows 1,000 custom properties at Starter, Professional and Enterprise alike, which is a ceiling almost nobody hits and almost everybody fills a quarter of with things nothing reads. Use the property insights tab to split the inventory three ways: properties carrying data and referenced by something, properties with no data, and properties nothing uses. Do not delete on sight. A property with no data may be new, and a property nothing references may be feeding an external report. Flag them, then ask.
- 3
3. Count workflows and lists against your limits
Marketing, Sales and Service Hub allow up to 300 workflows on Professional and 1,000 on Enterprise, Data Hub allows 400 and 1,100, the Brands add-on adds 100, and when you hold several subscriptions the highest limit wins. Only custom workflows built in the workflows tool count, so simple workflows from the ads, email and forms tools and automation from sequences, quotes and pipeline settings do not. Active CRM segments cap at 50 on Starter, 1,200 on Professional and 2,000 on Enterprise. Counting is the easy half. The useful half is finding workflows that are switched on but no longer enrol anyone.
- 4
4. Read the pipelines against the actual sales process
Deal pipelines cap at 2 on Starter, 15 on Professional and 100 on Enterprise, and pipeline sprawl is usually a symptom rather than a problem: it means teams could not express their process in the existing stages. Walk each pipeline stage by stage with someone who sells, and look specifically for stages that everything passes through in a day, which are usually recording an internal handoff rather than a buyer decision.
- 5
5. Find records near their association limits
In the Data Model limits tab, pull the view of records at eighty percent or more of their association limit and download it. Association limits can be configured up to 10,000, and each object pair supports up to 50 association labels, so a record approaching either ceiling is almost always an integration associating too broadly rather than a genuinely busy account. This check catches integration problems earlier than error logs do, because over-association does not fail, it accumulates.
- 6
6. Read thirty days of audit log
Filter to property and settings changes rather than logins, and look for edits nobody remembers making. Thirty days is short enough that this is a quick read and long enough to catch the change that broke a report last month. Note who is making structural changes. If the answer is four people across two teams with no coordination, that is a finding about ownership rather than about configuration.
- 7
7. Reconcile marketing contacts against your billed tier
Under Account and Billing, open Marketing Contacts and click through to usage and limits. Read the current count, the tier you are billed at, and any contacts scheduled to become non-marketing on a future date. This is the check most likely to find real money, for reasons covered in full below.
- 8
8. Inventory every system that writes into the portal
List the connected apps, the private apps, the data sync connections, and anything authenticating through a personal login rather than a scoped app. For each one write down what it writes, on what schedule, and who owns it. The entries you cannot complete are the audit's most valuable output, because an integration with no named owner is not maintained, it is merely still running.
The Limits Worth Counting Before They Bite
Most HubSpot limits are generous enough to ignore until the day they are not, and the failure mode is rarely an error message. It is a feature quietly refusing to do something.
| What | Starter | Professional | Enterprise |
|---|---|---|---|
| Custom properties per object | 1,000 | 1,000 | 1,000 |
| Calculated properties | 40 | 200 on Smart CRM Professional | 200 and above |
| Active CRM segments | 50 active, 1,000 static | 1,200 active, 1,200 static | 2,000 active, 2,000 static |
| Deal pipelines | 2 | 15 | 100 |
| Workflows | not available | 300, or 400 on Data Hub | 1,000, or 1,100 on Data Hub |
| Duplicate pairs surfaced | not available | 10,000 | 10,000, or 30,000 and 100,000 on Data Hub |
| API calls per day, private apps | 250,000 | 625,000 | 1,000,000 |
| API burst, private apps | 100 per 10 seconds | 190 per 10 seconds | 190 per 10 seconds |
Two of those rows deserve emphasis during an audit.
The duplicate pair ceiling is not a limit on how many duplicates you can have. It is a limit on how many the tool will show you, which means a portal at the ceiling has an unknown number rather than a large one. Treat a count sitting at exactly 10,000 as a measurement failure, not a data quality reading.
The daily API budget is the one integration teams discover in the worst possible way. It resets at midnight according to your account's time zone setting, so a backfill that starts in the afternoon can consume the day's remaining budget and stall every other integration sharing the account until midnight. The connected apps insights tab is where you see this coming, because it tracks daily call volume per private app and is built to surface spikes.
Where a CRM Audit Stops Short: the Integration Boundary
Everything above can be done from inside HubSpot by someone with Super Admin access. That is the good news and also the limitation, because the portal is downstream of every system that writes into it, and an audit conducted entirely inside HubSpot is auditing the output while assuming the inputs.
This is not a subtle gap. Three examples, all verifiable in HubSpot's own documentation.
Data sync excludes records silently, by design. HubSpot's data sync only syncs contacts with a valid email address by default, and only deals in mapped deal stages sync at all. Neither exclusion is an error. Both are settings behaving correctly, and both produce the same symptom: a record that exists in one system, does not exist in the other, and generates no failure anywhere. The Connected Apps CRM syncs tab does show records as In sync, Failing or Excluded, which is exactly the screen to open, and Excluded is the column that answers questions Failing cannot.
Records sync within ten minutes of a change, which is not the same as immediately. After the initial sync completes, changes propagate within ten minutes. That is fine for most processes and completely wrong for any process where someone acts on a record in the first few minutes of its life, which describes most inbound routing. A team can spend a quarter believing they have a data problem when what they have is a latency problem with correct data arriving after the decision.
The endpoint a sync leans on hardest is the tightest one. HubSpot's general burst limit is 190 requests per 10 seconds on Professional and Enterprise, but the CRM Search API runs at roughly 5 requests per second, and search is exactly what a naive integration uses to find the HubSpot record matching a row from another system. An integration that searches per record rather than carrying IDs will throttle long before it approaches the daily ceiling, and the daily usage graph will look reassuringly healthy while it does. Our guide to API integration covers this layer in detail, and the data mapping guide covers the field-level half.
If several systems write into your portal and nobody can produce a current field map, that is the audit finding. Everything else on the list is downstream of it. The Operations Hub guide covers what native data sync can and cannot express, which is usually where the boundary conversation starts.
The Finding That Costs Real Money
Most audit findings cost effort. One category costs cash, and it lives exactly on the boundary between HubSpot and whatever is writing into it.
HubSpot bills on marketing contacts, and new contacts do not all arrive with the same marketing status. Integrations and the API set contacts as non-marketing by default, which is the safe behaviour. Multiple object imports set them as non-marketing. Chatflows default to non-marketing. But HubSpot forms set contacts as marketing by default, and so do non-HubSpot forms, which means a third-party form tool wired into your portal is creating billable contacts every time it fires.
Then the billing mechanics make it stick.
This is the clearest illustration of why the boundary layer belongs in an audit. Nothing inside the portal looks wrong. The contacts are real, the form is working, the integration is healthy. The finding only exists if someone asks which system created these records and what status it assigned them, which is a question about the boundary rather than about the data.
Read the marketing contact count against the tier you are billed at, then trace the creation source of recent marketing contacts. If a form tool outside HubSpot is the answer, you have found something that pays for the audit.
What a Good Audit Deliverable Looks Like
The difference between an audit that changes something and one that gets filed is almost entirely in the shape of the output.
An audit that ends in decisions
- Every finding carries a verdict: fine, fix now, or accept deliberately
- Counts and screenshots with dates, so the next audit can measure change
- A named owner per integration and per unresolved item
- Fixes ordered by the cost of leaving them, not by ease
- The limits you are near, with the number and the tier
- A written field map for every system writing into HubSpot
- An explicit list of what was not checked
An audit that ends in observations
- Adjectives: messy, bloated, needs attention
- Counts with no baseline and no date
- A list of problems with no owner attached
- Fixes ordered by what the reviewer enjoys doing
- Generic best practice that names no limit at all
- No mention of what writes into the portal
- Silence about scope, so gaps read as a clean bill of health
That last pair matters more than it looks. An audit that does not say what it skipped will be read as having covered everything, and the integration boundary is the thing most commonly skipped and least commonly mentioned.
When a CRM Health Check Needs an Outsider
Plenty of teams should run this themselves. A team with a capable ops person and Super Admin access can cover the countable layer better than an outsider can, because they know which of the odd configurations were deliberate.
Bringing someone in is worth it when one of these is true.
Signs the review should not be internal
Nobody currently owns the integrations. The most common finding in any portal audit is an integration nobody claims, still running under credentials belonging to someone who has left. Whoever audits this has to be willing to say so, and internal reviewers are structurally worse at naming that than an outsider is.
Two systems disagree and both sides are confident. When HubSpot and an ERP or accounting system report different numbers for the same thing, the answer is almost never in either system alone. It is in the mapping between them, which means the review has to read both sides, and no one team usually has access to both.
The configuration predates everyone in the room. If nobody can explain why a property, pipeline or workflow exists, an internal audit will preserve it out of caution and the portal will never get smaller. This is the specific case where an outside reviewer earns the fee, because they will ask the question everyone else stopped asking.
You are about to build something on top of the data. Attribution reporting, forecasting, a customer-facing integration or a migration all assume the underlying records are correct. Auditing before that work is cheap. Auditing after it has been built on bad assumptions is a rebuild. The data migration guide covers what breaks when this order gets reversed.
The audit keeps getting scheduled and never happening. Not a technical reason, but the most honest one. If the countable pass has been on the list for three quarters, the constraint is attention rather than capability, and buying someone else's afternoon is a reasonable purchase.
One caution on who to hire. A full-service HubSpot agency will audit the marketing and process layers well, and is the right call if that is where your problem lives. An integration specialist will audit the boundary layer, and is the right call if the symptom is two systems disagreeing. Neither is better in the abstract, and the mismatch to avoid is buying a marketing-shaped audit for an integration-shaped problem, because the report will be genuinely competent and answer a question you did not ask. The guide to HubSpot consultants covers how the roles actually differ, and choosing a HubSpot partner covers what the tier badges do and do not tell you.
Two systems disagreeing and nobody can say which one is right?
StackTie audits the layer most reviews skip: what every connected system writes into your portal, on what schedule, under whose credentials, and where the mappings have quietly stopped matching reality. The audit call is free and ends in a written list of what is worth fixing and what is not, including the parts we would leave alone. If a build is the answer, we do that too, live in 14 days or your money back.
The Bottom Line
A HubSpot audit is mostly arithmetic, and HubSpot does most of the arithmetic for you. The data quality overview counts duplicates, formatting issues and unused properties. The Data Model limits tab counts everything approaching a ceiling and flags records above eighty percent of their association limits. The audit log holds thirty days of who changed what. The connected apps insights tab tracks per-app API volume and surfaces expired connections. Working through those four screens is an afternoon, and it covers most of what a checklist-style paid audit will report back to you.
What that pass cannot do is see outside the portal. Data sync excludes records silently by design, changes land within ten minutes rather than immediately, the search endpoint a sync leans on hardest is metered far tighter than the general API, and a form tool sitting outside HubSpot can create billable marketing contacts that push you into a higher tier you then pay for until renewal. None of those show up as errors. All of them show up as a portal that has stopped describing the business.
So run the countable pass yourself, quarterly, and treat it as maintenance rather than as a project. Then spend outside money on the boundary: the field maps, the ownership gaps, and the systems writing into HubSpot that nobody has looked at since the day they were connected. That is where audits find things worth the trouble of having looked.
