Support
Support in the sidebar is where you ask us anything about an organization — a limit, a bill, a build that will not come up, an account somebody cannot sign in to. A person answers these, so it will not be instant, but nothing is filtered or triaged by a robot on the way in either.
A request belongs to the organization it is about, so anybody in that organization can read the thread and reply to it.
Asking
Pick what it is about, say what you need, and send it. The subject is optional — leave it empty and we take the first line of your message, which is usually the right title anyway.
The topic is a hint for whoever picks the request up, not a filter that decides whether we read it:
| About | What belongs there |
|---|---|
| Account limits | You have been refused a deploy, or want to know what this account may run |
| Billing and credit | Credit, top-ups, or a figure on the ledger you cannot account for |
| Deploying and builds | A build that failed, a revision that will not come up, or compose we would not accept |
| Account and access | Signing in, members, API tokens, registry keys |
| Something else | Anything that is not one of the above |
"Something else" is a real answer, not a bin. If nothing fits, use it — we would rather have a request filed honestly than filed neatly.
The more of the actual shape of the problem you can give us — what you were doing, what happened, what you expected — the fewer times we have to ask back.
If you were refused a deploy
Every refusal links here, and for a capped account the page puts the ceilings first, before the form: what this organization may run, and the two ways out of the new-account tier.
Two things about a limit are worth knowing:
- It refuses the next deploy and never stops anything already running. Going over a ceiling costs you the deploy, not the site.
- The ceiling belongs to the organization, and the organization takes the tier of its most trusted member. A colleague who is already past the new-account tier lifts it for everyone, so inviting somebody established is a real answer to "how do we get more room".
Getting out of the new-account tier takes one of two things, whichever happens first:
| Route | What it takes |
|---|---|
| Wait | 60 days from when the account was created |
| Pay | $100 in top-ups, at which point the account graduates immediately |
Both are properties of your account rather than of the organization, and the page shows how much of each is left. If an operator has pinned your account to a tier, neither applies and the page says so — asking is then the only route.
Once there is nothing capped, the ceilings disappear from the page entirely and one line at the foot says so.
Following a request
A sent request opens its own thread. While nobody has picked it up yet, it says so rather than leaving you to guess from the absence of a reply.
When we answer
The reply lands as a notification for everyone in the organization, with the text of the answer in it, so you do not have to keep coming back to check.
If we mark a thread resolved and you are not done, just reply — that reopens it. There is nothing to reopen by hand and no need to start a second request.
For operators
Every tenant's requests land in one queue at Admin → Support, oldest unanswered first, with a count on the sidebar so nothing waits unnoticed. Each row carries what it is about, so a declined card and a refused deploy are visibly different things in a list of twenty.
Opening one puts everything the decision needs beside the conversation: who is asking and what tier they are on, what the organization is running against its ceilings, and what it has left to spend.
Lifting a limit happens on this screen, not on the user panel. The pin applies to the person who asked (every organization they are in takes the higher tier), it records the reason, and it returns you here — so the reason gets written while the conversation that justified it is still in front of you.
Marking a thread resolved tells nobody, deliberately: it is bookkeeping. A tenant reply reopens it either way.