An Opensolr plan limits how many indexes an account may hold, and Loghound needs two. Discovering that halfway through provisioning would mean one index created, one refused, and a bill for the orphan — so the account is counted before the first create.
The wizard stops with the numbers and creates nothing:
Your Opensolr plan allows 4 indexes and 4 are already in use, so there is room for
none more and Loghound needs 2.
xx There is no room on this plan for the two indexes Loghound needs.
- Delete an index you no longer need, which frees a slot immediately.
- Move to a plan that allows more indexes.The browser installer withholds the create control rather than letting you press something that can only fail, and both front ends offer only the routes that genuinely exist for that account. Joining a pair you already have is offered first when there is one, because it creates nothing and the limit does not apply to it.
Figure 1 — the two guarantees. Counting first means you are never told halfway through; the rollback means that even when the count was right and the race lost, you are not billed for an orphan.
The platform reports the allowance, the usage and the remainder from the same account endpoint, built from the same two calls the platform’s own create gate consults — so the number Loghound shows and the number the platform enforces cannot drift apart. The usage counts standalone indexes only, exactly like that gate.
A stored allowance goes stale the moment a plan changes, and it goes stale silently. There is no configuration key holding it, and a test in the Loghound suite asserts that there is not.
Two cases answer “unknown” rather than a number, and neither blocks you:
- An account holding nothing. The endpoint is scoped to one index the account owns, so an empty account has nothing to name and its allowance cannot be read at all.
- A platform older than those fields. Missing fields are read as unknown rather than as zero — a zero there would say “your plan allows no indexes” and refuse an operator whose plan is perfectly fine.
Refusing on a number nobody has would strand somebody for no reason, so the guarantee is kept where it still can be — which is the next section.
Another session can take the last slot between the check and the create. So the half-way failure is handled regardless: when the second create is refused, for any reason, the first index is deleted and you are told that nothing was left behind.
ok Creating the hits index - Created loghound_9ce6e3c9_hits.
xx Creating the sessions index:
Your Opensolr plan allows 4 indexes and 3 are in use, so there is room for the 2
Loghound needs. ...
Removing loghound_9ce6e3c9_hits, which this attempt created and will not be using
Removed loghound_9ce6e3c9_hits. Nothing has been left behind on your account.That rollback is unconditional. The platform’s refusal message is still recognised, but only to report the race cleanly — not to discover the allowance.
Opensolr index names are unique across the entire platform and are never released. That is why a failed attempt deletes what it created before retrying, and why the uninstaller makes deleting the two indexes a separate question that --yes cannot answer.
If the plan really is full, the honest options are to delete an index you no longer need in your Opensolr control panel, to move to a plan that allows more, or to join a pair this account already holds.