Back to Blog
AnalyticsBusiness Operationsdata analysis

How to Measure Parking Facility Occupancy

Calculate parking occupancy with a defined space count, validate the inputs, and build enough observation history to report measured peaks responsibly.

Parking occupancy is the number of occupied spaces divided by the number of usable spaces at a specific moment, times 100. The formula is the easy part. Before you trust the result, confirm what your capacity and available-space numbers mean, record when each reading was taken, reject invalid records, and collect readings over time. One reading describes one moment; it cannot establish the busiest time of a day or week. Manual counts, gate and payment records, and sensor or feed data can all help if you check their scope and limitations.

Three Different Numbers People Call “Occupancy”

When someone says a lot is “at 60%,” they could mean one of three things:

  • Occupancy at a moment: occupied spaces ÷ usable spaces at one time. “At 10:15 Tuesday, 180 of 200 spaces were taken: 90%.”
  • Observed peak occupancy: the highest reading in your sample across a defined period, such as a day or a week. Report the count times and number of readings; sparse sampling can miss the true peak.
  • Average utilization: the share of available space-hours that were used over a period. A 100-space lot open 10 hours has 1,000 space-hours available. If cars occupied 600 of them, utilization is 60%.

These answer different questions. Utilization tells you how much of your capacity earns its keep over the day. Peak tells you whether you ran out of room.

Mixing them up is the most common occupancy mistake. A garage reports 45% occupancy to its owner, a 24-hour average. It was effectively full from 11:30 to 1:30 every weekday, turning drivers away. Both statements are true. Only one of them helps anyone decide whether to add permits, change prices, or send overflow elsewhere.

The Formulas

Occupancy % = occupied spaces ÷ usable spaces × 100, measured at a stated time.

Three details decide whether that number is right.

Use a capacity denominator that matches the spaces being counted. Design capacity is every striped space. Usable capacity excludes spaces closed for repairs or blocked by construction or snow. If you report general-access parking separately, also exclude reserved, accessible, or loading spaces from both the numerator and denominator for that specific pool; do not drop them from a total-facility occupancy figure. A 200-space garage with a closed level of 40 spaces that fills its remaining 160 is 100% full, not 80%. State which capacity you used.

Deriving “occupied” from “available” works only if both describe the same spaces at the same time. Many systems report empty spaces rather than occupied ones. Occupied = capacity − available is correct only when the capacity and the available count cover the same set of spaces and were recorded at the same moment.

For gate or entry/exit systems, count the accumulation. Occupancy at a given time = the starting count + entries − exits. If 40 cars are inside at 6:00 AM, 180 enter and 95 leave by 10:00 AM, accumulation is 125 cars inside at 10:00. Divide that by usable capacity to get the occupancy rate. Accumulation drifts over time (more on that below), so it needs a regular reset against a physical count.

Before You Calculate: Check What Your Data Means

I’m building an analytics project on Istanbul’s municipal parking network, which publishes a live feed of its facilities with capacity and empty-space counts. Before calculating a single occupancy figure, I audited what the feed actually returns. The arithmetic turned out to be the least of it.

Here’s a real reading from one snapshot on 2026-08-22. Facility 3068, an enclosed garage listed as open 24 hours, reported a capacity of 1,029 and 589 empty spaces at 02:31 Istanbul time. That’s 1,029 − 589 = 440 occupied, or 42.8%.

The calculation took one line. The audit found five things that would have made numbers like that wrong without anyone noticing:

  1. Invalid requests return a normal-looking record. Asking for a facility ID that doesn’t exist returns a record with a capacity of 1 and 1 empty space instead of an error. Included in a calculation, it looks like a tiny, empty lot. Lesson: define what a valid record looks like and reject the rest before you calculate.
  2. The facility list has no timestamp. The list doesn’t say when each reading was taken. Lesson: if the source doesn’t timestamp a reading, record the time you retrieved it. A reading you can’t place in time can’t be part of a peak.
  3. A status field has no documentation. The isOpen field is 0 for most facilities, including facility 3068, which lists 24-hour operation. Lesson: don’t guess what an undocumented field means. Leave it out until you can confirm it.
  4. A time field has no timezone. The detail record’s update time doesn’t say which timezone it’s in. Lesson: confirm timezones before comparing readings from different sources.
  5. There’s no history. The feed shows only the current state. Lesson: covered in its own section below.

Your data will have different quirks, but the questions carry over to any lot, garage, or system:

  • What exactly does “capacity” include? Does it change when spaces close?
  • What does “available” or “empty” mean, and does it cover the same spaces?
  • Where does each reading’s timestamp come from, and in what timezone?
  • What does an invalid, closed, or offline record look like?
  • Does the source keep history, or only the current state?

The project’s code and evidence are public at github.com/johnserra/istanbul-parking-analytics. These figures come from a single audit snapshot. They aren’t a finding about how full Istanbul’s garages are.

Istanbul parking data source: Istanbul Metropolitan Municipality (IBB) Open Data Portal, 2026-08-22 audit snapshot. The IBB Open Data License v1.0 requires this attribution: “Contains public sector information licensed under the Attribution 4.0 International (CC BY 4.0).”

Three Ways to Collect Occupancy Data

Manual counts

Someone walks the facility on a schedule and counts occupied spaces. It costs staff time and nothing else, and it’s the most direct measurement there is.

Choose count times from how the facility is used. An office garage, a retail lot, a hospital, and an event venue peak at different times, and a single universal schedule will miss some of them. Count at the times you expect to be busiest, plus a quiet period for comparison, on the days that matter (weekdays, weekends, or both). Record each count with its date and time on a simple sheet.

Gate, ticket, and payment records

If your facility has gates, ticketing, or pay-by-plate, you can reconstruct occupancy from entries and exits, usually in 15- or 30-minute intervals. The data already exists, so this is often the best place to start before buying anything new.

The catch is drift. Tailgating, unreadable tickets, gate arms left up, and cars that exit without being recorded all push the running count off over time. Reset it against a physical count at a known quiet point on a regular schedule, and compare the two to see how far it drifted.

Sensors, cameras, and live feeds

Per-space sensors, entry counters, camera counts, and live data feeds give you frequent readings without anyone walking the lot. They’re worth it when a decision needs real-time information, such as guidance signs showing available spaces or prices that change by time of day.

Automation doesn’t skip the checks above. A sensor feed has its own capacity definition, its own offline states, and its own timestamps, and all of them need confirming. For planning questions that do not need a live feed, start by testing whether counts and existing records answer the question before paying for hardware.

One Reading Isn’t a Peak: Build Your Own History

The Istanbul feed only reports the current state, so my project stores a snapshot each time it reads the feed. Without that, there’s no history. The same is true of most live feeds and many gate-system dashboards: they show you now, and “now” disappears.

Two rules from the project carry over:

  • Keep the raw readings, not only the calculated percentage. If you later find that a capacity figure was wrong or an invalid record slipped through, you can recalculate.
  • Match the claim to the history you have. My project won’t forecast occupancy or trigger capacity alerts for a facility until it has 26 weeks of readings with at least 90% coverage. That’s a high bar for forecasting. For simple peak reporting, the practical version is to say what the peak is based on: “Peak of 96% at 10:30 on Tuesdays, from 18 weekday readings over three weeks” is an honest statement. “Peaks at 96%” from one busy morning isn’t.

What Counts as “Full”?

You may see 85% cited as a parking occupancy target. That number comes from a point-in-time curbside-parking context, not a universal goal for lots or garages. For example, SFMTA’s SFpark policy describes a commonly cited 85% curbside threshold at a single moment while using a 60–80% average occupancy target across a longer period to keep spaces available on each block. Those are different measurements and settings; neither gives your facility its own “full” threshold. Practitioners have also questioned relying on any occupancy target alone: in a May 2026 Parking Today piece, Cole Jaillet argues that occupancy is a snapshot rather than a behavior, and that two blocks at the same percentage can serve very different numbers of vehicles depending on how long each stays.

For a specific facility, set two thresholds from its own history: a “busy” level where drivers start having trouble finding a space, and a “full” level where the facility is effectively out of room. Look at the readings from times you know were difficult (complaints, turned-away drivers, staff reports) and see where occupancy stood. Then report how long the facility stayed above each threshold, not only whether it crossed.

A Two-Week Occupancy Audit

If you’re starting from nothing, this gives you a defensible baseline:

  1. Set usable capacity and write down exactly what you counted and excluded.
  2. Choose count times from the facility’s use pattern. Cover weekdays and weekends if both matter.
  3. Record every count or snapshot with its timestamp in one sheet. Keep the raw numbers.
  4. Reconcile counts with transaction and permit records for the same times. Account for vehicles already present, exits, permits, validations, and unpaid sessions before treating a gap as a counting or payment problem.
  5. Report peak, time near capacity, and how many readings each is based on. End with one follow-up action, an owner, and a date.

Once occupancy is reliable, it can support revenue analysis when you also have revenue records for the same facility and period. Occupancy data alone cannot show what a space earned. A full lot of monthly permit holders and a lot turning over transient drivers can look identical on an occupancy chart while producing very different revenue, which is why revenue per space needs its own treatment.

Frequently Asked Questions

What is the formula for parking occupancy rate?

Occupied spaces ÷ usable spaces × 100, measured at a stated time. Use the spaces actually available at that moment, not the design total.

How often should parking occupancy be measured?

Often enough to sample the periods when your facility is likely busiest. For manual counts, that may mean several readings across the expected peak. Automated intervals should match the decision you need to make and the feed’s actual update frequency. State how many days and readings your observed peak covers.

Is 100% occupancy good?

Not usually. A lot at 100% is turning drivers away and has no room for permit holders who arrive late. How far below full a facility should run depends on its layout and its customers.

Can I measure occupancy without sensors?

Yes. Manual counts and gate or payment records answer most planning questions. Sensors earn their cost when a decision needs real-time data.