San Francisco 90-Night Cap, Explained

San Francisco applies a 90-night cap to unhosted short-term rental stays. That cap is specific to San Francisco and to unhosted stays: a host away from the property, letting the whole unit, counts those nights against 90 in the city's counting period. Hosted stays, where the host is present, are treated differently under city rules, and hosts must confirm the hosted treatment from current sf.gov guidance rather than assuming the same cap applies.

The distinction between hosted and unhosted is therefore the first tracking decision. A host who mixes hosted and unhosted stays needs two counts, or a single log that labels each stay hosted or unhosted, so the unhosted total can be isolated. A blended total that mixes both patterns cannot answer a cap query about unhosted nights. Label every stay at booking time.

Count unhosted nights let, per property, in the city's counting period, confirming the period start and any exclusions on sf.gov before building a tracker. Count by nights, not bookings, and combine all platforms plus direct bookings into one tracker. A stay spanning a month boundary counts its nights across that boundary, and an extension adds nights to the unhosted total if the extended nights remain unhosted.

Cancellations and alterations need care. A cancelled unhosted booking should not count as nights let, but a booking altered from hosted to unhosted, or vice versa, changes which count it belongs to. Record the pattern as actually operated, not as originally booked, and keep alteration messages with the stay record so the final classification is provable.

As the unhosted tracker approaches 90, block further unhosted dates on every platform and for direct bookings simultaneously. Hosted stays, if permitted under the host's certification and city rules, may still be possible where they are genuinely hosted, but hosts should not re-label unhosted stays as hosted to circumvent the cap. Re-labelling without genuine presence is a misdescription that enforcement can detect through occupancy patterns.

If bookings already exist that would exceed the unhosted cap, seek city guidance promptly. Letting them run in the hope that the count is not checked creates a breach that could have been avoided by rescheduling or converting to a lawful alternative where applicable. Early action, even if it means cancellations, is usually cheaper than an enforcement record.

Platforms may warn or block dates as a property approaches an unhosted cap on that platform, but no single platform sees the host's total across channels. A host who lets through two platforms plus direct bookings may exceed 90 while each platform shows a lower total. The host's combined, pattern-labelled tracker is the authoritative count, and platform warnings should prompt a check of that tracker, not replace it.

Hosts should reconcile platform unhosted totals with their own tracker monthly, noting differences and explanations. A monthly reconciliation takes minutes for a single property and prevents a year-end surprise. For multiple properties, reconcile per property, since caps apply per property, not per host.

Keep a pattern-labelled stay log, platform statements, certification details, and the city counting rule as published, filed per property per period. If the city queries unhosted nights for a period, that file shows each unhosted night, its booking reference and its channel. A host who can show unhosted nights night by night, separated from hosted nights, resolves queries far faster than a host with a single blended total.

Annual reconciliation should compare unhosted nights against 90, hosted nights against their own city treatment, total income against tax records, and platform activity against direct activity. Do it before the next counting period, while evidence is accessible.

Confirm hosted versus unhosted treatment on sf.gov, label every stay, track unhosted nights combined across channels, block dates as 90 approaches, reconcile monthly, and recheck city guidance before each season. This guide is general information only, last verified on 26 October 2026.

Consider a San Francisco host who lets a whole unit unhosted through two platforms and occasionally directly. In March the host records four nights on the first platform, three on the second, and two direct nights, all unhosted. The combined unhosted total for March is nine, even though no single platform shows more than four. A host who looked only at the largest platform would understate March by five nights, and a host who repeated that error across a year could breach 90 while every platform dashboard looked comfortable.

That example shows why the host's own log, not any platform dashboard, is the cap authority. Build the log as a simple table with one row per stay: start date, end date, nights, pattern label, channel, booking reference. Sum the unhosted rows for the counting period whenever a new booking is considered. If the sum plus the proposed stay would exceed 90, the proposed stay cannot be accepted as an unhosted stay in that period. That rule, applied booking by booking, is simpler than any annual reconciliation and far more reliable.