Why We Publish Our Limits

Every system has a ceiling somewhere

Every real system running at any scale has ceilings like these, whether or not anyone talks about them: rate limits, session lifetimes, request sizes, retention windows, the maximum number of something a single account can create in a day. The only actual choice a vendor makes is whether those ceilings are written down where a customer can read them before signing, or left to be discovered later, usually at the worst possible time to discover them.

This is easy to accept in the abstract and consistently ignored in practice, because a sales conversation rewards saying yes. 'Can it handle this volume?' 'Yes.' 'Can sessions stay alive this long if we need them to?' 'Yes.' Each individual yes feels harmless in the moment, and each one quietly commits the vendor to a number they may not have actually tested, or may walk back later once the account is live and the constraint becomes real. A vendor that answers capacity questions with a specific, published figure instead of an agreeable yes is taking on more short-term friction in the sales process in exchange for not owing anyone an uncomfortable conversation after the contract is signed.

The cost of discovering a limit in production

There's a specific, recurring failure pattern worth naming: an integrator finds a rate limit by tripping it during a real traffic spike, or finds a retention window by asking, mid-incident, where a record everyone assumed still existed actually went. Both are the same limit a vendor could have published on a docs page, encountered instead at the worst possible moment, by someone who had no way to plan around it because nobody told them it existed. A documented limit, read calmly during evaluation, is a planning input: you design around it, or you ask about raising it, or you decide it doesn't matter for your use case. The identical limit, discovered blind in production, is an incident and a mark against the vendor's credibility, even though the limit itself hasn't changed at all. The only thing that changed is whether anyone was told.

Why vendors avoid publishing limits

It's worth being honest about why undocumented limits are so common, because the reasons aren't stupidity: they're incentives. A published number is a target: someone will ask why it's that number and not a higher one, and answering that question honestly sometimes means admitting a constraint the vendor would rather not discuss in public. A published number is also a commitment a vendor has to defend and can be held to later, whereas an unpublished one can be quietly adjusted (tightened during an incident, loosened for a big account) without ever having said a specific figure out loud that someone could point back to. Not publishing is, in a real sense, easier. It just moves the cost from the vendor, who avoids an uncomfortable conversation, to the customer, who finds out the hard way.

What publishing forces internally

There's a less obvious benefit to publishing limits that has nothing to do with the customer relationship: you cannot publish a number you can't explain. Writing 'sessions expire after this many hours of inactivity' on a public page, with a reason attached, forces the team that owns that number to actually know why it's set where it is, rather than treating it as an emergent property of whatever the infrastructure happened to default to. That discipline (being able to say why a ceiling exists, not just that it does) tends to generalize. A team that can explain its session lifetime can usually explain its rate limits, its retention windows, and its key rotation cadence too, because the habit of justifying a number before writing it down doesn't stay confined to one setting.

A limit is not a flaw

There's an unstated assumption behind why vendors hide limits: that having one is embarrassing, evidence of a system that isn't infinitely capable. That assumption is backwards. An identity platform that claims to have no limits anywhere hasn't demonstrated more capability: it's demonstrated less scrutiny, because nobody has sat down and worked out where the actual ceiling is and why it's there. A published limit that comes with a reason is evidence of the opposite: that someone examined the trade-off and made a deliberate choice. 'Sessions expire after a bounded period of inactivity, because an indefinitely valid session is a standing target for credential theft' tells a buyer something real about the security posture behind the number, not just the number itself.

A limit is not the same thing as a bug

It's worth separating two things that get conflated in these conversations. A limit is a deliberate ceiling, chosen for a reason, that a team can explain and defend: a session that expires after a bounded period, a rate limit sized against known abuse patterns, a maximum retention window chosen to balance usefulness against exposure. A bug is a ceiling nobody chose, discovered by accident, that exists because a resource ran out or an assumption baked into the system turned out to be wrong under load nobody anticipated. Vendors that avoid publishing limits are often, whether they'd put it this way or not, avoiding the discomfort of a customer being unable to tell the two apart from outside. Publishing forces the distinction to be made explicitly, on the vendor's own terms, before a customer has to guess which one they just ran into.

Limits change: the point is that the change is visible

Publishing a limit isn't a promise it will never move. Capacity grows, usage patterns shift, and a number chosen conservatively at launch sometimes turns out to be tighter than it needs to be once real traffic proves it out. The commitment worth making isn't that the number never changes: it's that a change is announced, dated, and explained the same way the original number was, rather than quietly adjusted in a way only someone who happened to hit the new ceiling would ever notice. A limit that moves without anyone being told isn't meaningfully different from a limit that was never published in the first place; the whole value of publishing it was that customers could plan against something stable enough to trust, and silent changes destroy exactly that.

How to read a vendor's published limits, if you can find them

When evaluating a vendor, look specifically for limits that come with a stated reason attached, not a bare number sitting alone in a table. A number with no reason is often just whatever the infrastructure allowed, discovered after the fact rather than chosen on purpose. A number with a reason tells you the team behind it understands the trade-off it's making, which is the same discipline you want governing decisions you can't see: how credentials are stored, how a session gets revoked, what happens when a dependency goes down. A vendor's willingness to be specific and public about its own ceilings is a reasonable proxy for how it handles the requirements nobody's asking about yet.

The alternative to a limit is usually a worse limit in disguise

A vendor without a published ceiling doesn't actually have infinite capacity: it has an unpublished one, enforced ad hoc, usually discovered by whoever happens to push hardest against it. That's a worse outcome for almost every customer, not a better one, because it means the ceiling you get depends on how loudly you complain rather than on a stated policy applied evenly. A published limit, even a modest one, is a form of fairness: everyone is working against the same stated number, and raising it is a documented conversation rather than a negotiation that rewards whoever escalates first.

The limit we state about ourselves

We don't hold a formal third-party security certification yet, and we say that plainly rather than implying otherwise: no SOC 2, no ISO 27001, stated the same way we'd state any other limit, what it is, and why it's true today. Publishing the uncomfortable limits alongside the comfortable ones is the only version of 'honest about our limits' that means anything. Publishing only the flattering ones and staying quiet about the rest is just marketing wearing a transparency page as a costume.