Algeria AgencyIT & infrastructure
The account, not the server: what you actually lose in the cloud
Everything you keep there passes through one login, one mailbox and one card. What breaks that chain, and in what order.
The companion article is about cost: what is rented rather than bought, why storage is the cheapest line, what leaving costs, and the day the bill doubles. It is an economics page and it is complete.
This one is about something else: who can still get in. Everything your business has put there is reachable through one login, held by one person, attached to one mailbox and one bank card.
None of the failures described here is a provider failure. The platform works perfectly throughout the four weeks you cannot get in, and that is exactly what makes the problem invisible before it happens.
The sections are ordered the way things actually break: ownership first, then the address, then the card, then the clock that runs when nothing answers any more.
The account is the asset, not the server
The neighbouring article opens by saying a purchase became a rental. This one opens on the consequence nobody draws: what you own is no longer a machine sitting somewhere, it is a right of access.
A machine is visible. It is in a room, it can be unplugged, opened, its disk taken out. A right of access is not visible, does not inventory itself, and disappears with no noise and no physical trace.
The practical difference shows up the day somebody has to take things back over. With a machine, the worst case is a forgotten password and a disk you extract. With an account, the worst case is that there is no way in at all, however willing everybody is.
That is what makes this subject different from every other in this pillar. For a server in a room there is always a last physical resort. For an account, the last resort is a provider procedure written for a general case, which you answer with whatever you have to hand — which is exactly what this page asks you to prepare.
So hold the formulation that makes the rest readable: your hosting is not a place, it is a chain of three links — a login, a recovery address, a means of payment — and each section that follows deals with one link.
Whose account is it
In the large majority of businesses we see, the account was created by whoever built the site, with their own personal address, one evening, to save time.
Nothing in the account carries the company’s name. The invoice goes to an address you do not read, payment runs on a card that is not yours, and the identity declared to the provider is an individual’s.
While the relationship is good this produces no symptom at all. That is what makes it dangerous: there is no moment where something starts working badly and warns you.
What to aim at is three points, none of them technical. The account’s contact address is a company address. The billing details carry the registered name and the tax identifier. And the individual recorded as holder is somebody who will still be there in three years.
The moment to make that change is now, while things are fine, and it is the only advice in this article with an expiry date. A transfer of ownership requested from a provider whose relationship with you has ended is a request they are neither obliged nor inclined to process.
The address that opens everything
The second link is the mailbox attached to the account, and it matters more than the password. Whoever receives the recovery messages can take the account back; whoever does not cannot, even knowing the password.
Three mistakes repeat. A personal address, which leaves with the person. An address that no longer exists, a former employee’s. And the most elegant of the three: an address hosted on the very service the account runs.
That last one deserves a sentence, because it is circular and you only see it from inside. If your business mail runs on the hosting, and the hosting is suspended, then the message that would let you recover the hosting arrives in a mailbox that no longer works.
The right shape is dull and solid: an address in the company’s name, redistributing to two people, hosted somewhere other than the service concerned. A redistribution rather than a mailbox, so that one of the two leaving breaks nothing.
Check it today, in two minutes, changing nothing: open the account, read the contact address, and ask yourself who exactly reads that mailbox this week. It is the most profitable check in this whole article.
Two-factor authentication, and the key one person holds
Enabling two-factor authentication on the main account is right, and it is also the commonest cause of permanently losing access at this size of business. Both statements are true at once.
The mechanism is simple: the second factor is nearly always an application on a phone, and a phone gets lost, broken, stolen and replaced. The account knows only that phone.
Providers plan for this and issue single-use recovery codes at the moment of activation, once. Those codes are the account’s real key. Almost nobody writes them down, because they are displayed at the moment everybody is in a hurry to finish.
So the rule is to print the recovery codes and put them in the safe, with the date and the account name. On paper, deliberately: a recovery code stored in a password manager that itself runs on the service concerned takes you back to the circularity of the previous section.
And plan for a second holder. Two people whose phones are enrolled, or one person plus the envelope in the safe — the choice matters less than the fact of having made one. An account only one person can get past the second step of is an account that depends on a phone.
The card: what begins when it is refused
The neighbouring article explains how to pay a foreign service from here and we are not repeating it. What interests us is the other direction: what happens on the day the payment stops going through.
The causes are ordinary and undramatic. A card that expires, a monthly ceiling reached, a card replaced after a stop order, a bank blocking a repeated international transaction. None of them makes any noise at your end.
What follows is a sequence, always the same one: a first payment-failure message, several reminders over a few days, then suspension of the service, then — much later but genuinely — deletion of the data.
The point that decides everything is that this entire sequence runs by email, to the address from section 2. If that address is not read, you learn the problem exists at the moment the site stops, which is the middle of the sequence rather than the beginning.
Two protections cost a morning. A second means of payment registered on the account, which takes over by itself. And a note in the company diary in the card’s expiry month, because it is the only one of the four causes known in advance and avoidable in full.
The clock that runs when nothing answers
Suspending is not deleting, and that distinction is your main room for manoeuvre. Between the two there is a period during which everything is recoverable by simply settling the invoice.
We are not going to give you that period in days, and that is deliberate. Every provider publishes its own, they differ a great deal, and a number printed here would be somebody else’s contract applied to yours — the only figure that matters is the one **your** provider publishes.
Go and find it once, it is in the terms of service, and write it on the sheet from section 10. The search takes a quarter of an hour and never has to be repeated.
What you do need to know instead is what the period does not cover. A fixed IP address, an attached domain name, a rebuilt machine: several things do not come back identical after a suspension, even when the data does.
And hold the order, because it is counter-intuitive: the data is the last thing deleted and the first thing everybody believes lost. The panic arrives at suspension, whereas the useful window opens at exactly that moment.
The provider who leaves with the account
This is the commonest way, in this country and at this size of business, to lose everything you put there — and it has nothing to do with a dispute or bad faith.
The freelance developer, the previous agency or the cousin who knows about these things created the account with their own credentials, because it was simpler, and because nobody thought to ask for anything else. They deliver the work, they are paid, the relationship ends well.
Two years later they have changed trade, country or number. The account is in their name, the card was theirs, the recovery address is theirs, and nobody has anything against them. There is no culprit and there is no solution.
The request to make fits in one sentence and is put before signing: the account is opened in the company’s name, with its address and billing details, and the provider is invited into it as a user. That is exactly the norm in the other direction — nobody finds it strange that an accountant works on the company’s books rather than their own.
If you are already in the situation, deal with it while the relationship is cordial rather than at the moment it ends. A transfer requested today is a ten-minute formality; the same transfer requested after a disagreement over an invoice goes nowhere.
Three named accounts, and a main account nobody uses
The main account is the one that can do everything, including closing the service and changing the means of payment. It should not be the one used for daily work.
The shape that works at this size is simple: the main account handles billing and nothing else, and two or three named users do the daily work with their own credentials.
The benefit is not theoretical and it comes in two forms. A person leaving is handled by removing their access rather than changing a password three people know. And the provider’s own logs become readable: "who deleted this machine" has an answer.
If you share a single login today — which most readers do — the way out takes an hour and goes in this order: create the named accounts, check they work, then change the main account’s password, and not the reverse.
It is the same rule as the access-control and firewall pages of this pillar, and it fails in the same place every time: a shared login is not a shortcut, it is the absence of an answer to the one question somebody will eventually ask.
What is running that nobody remembers
After two years, every account of this kind contains something nobody decided to keep: the former developer’s test machine, the previous site’s database, a backup started once.
These things go unnoticed, because they never break down and because they appear on the invoice under a name nobody recognises. They are not very expensive and they do something else that matters more: they make the invoice unreadable.
And an unreadable invoice is what stops you seeing the real information. The neighbouring article deals with the day the amount doubles; what we add here is that an amount can only be argued about if every line carries a name you understand.
The remedy is two habits. Naming resources plainly at the moment of creation — the project name and the year, not a string of characters. And reading the invoice for five minutes a month looking for one thing: a line you cannot say the purpose of.
That quarter of an hour has a second effect, more useful than the saving: it makes you know what your business actually owns there. It is the only honest way to keep an inventory of an asset that is not in a room.
The spend alert, set at an amount that means something to you
This is the only automatic thing in the whole article, it takes ten minutes to set, and almost nobody does it.
Every serious provider lets you set an amount above which a message is sent. The setting is trivial; what needs a decision is the amount.
Choose a figure that would make you react, not a theoretical one. An alert set at three times your usual bill will only fire after the damage; one set just above it fires for nothing every two months and will be ignored within four.
The right marker is your normal bill plus half. It catches what matters — a forgotten resource running, abnormal traffic, a configuration error multiplying a consumption — and stays quiet the rest of the time.
Send the alert to the address from section 2, not to a personal address, for the same reason as everything else on this page: a signal arriving in a mailbox nobody reads is not a signal.
The sheet to write once
Everything above fits on one A4 page, and that page is this article’s real deliverable. It lives in the safe or the company file, not in the service it describes.
Eight lines are enough: the provider, the access address, the account’s contact address, who receives the recovery messages, where the recovery codes are, the card’s expiry month, the billing day, and the period before deletion looked up in section 6.
Do not put the password on it. This sheet is not a keyring, it is a map: it tells somebody else what to do and where to look, not how to get in.
It is distinct from the contract the neighbouring article discusses, and both are useful at different moments. The contract says what the provider owes you; this sheet says what your business knows about its own account.
Date it, and reread it the day somebody leaves or a card is replaced. Those are the only two events that make it stale, and both are visible.
What we do, and what we refuse to do
What we refuse first: opening an account in our agency’s name for a client, even when it simplifies everything at the start, which it always does at the start.
The reason is not a matter of principle, it is concrete: it makes leaving impossible. A client who wants to work with somebody else in two years has to be able to, without our cooperation, and that is exactly what an account in our name takes away from them.
We also refuse to be the sole holder of a client’s recovery codes. We can set them up, print them and hand them to you for the safe; we do not keep them, because a provider holding the last key is a provider you can no longer do without.
What we do gladly: the tidy-up. Half a day to open the account in the company’s name, attach a recovery address that redistributes, create the named users, set the alert, and write the sheet with you.
And one thing to do today, without us, in two minutes: open your last hosting invoice and look at what address it went to. If nobody reads that mailbox this week, you already have the one problem all the others depend on.
Frequently asked questions
Our site was built by a provider. How do we know whose account it is?
Look at who receives the hosting invoices: the billing address is the best indicator and it is visible on any invoice. If you have never received one, the account is not yours. Ask for a transfer of ownership while the relationship is good — it is a formality today and a problem with no solution in two years.
What email address should be on the account?
An address in the company’s name, redistributing to two people, and hosted somewhere other than the service concerned. That last condition is the least obvious and the most important: if your mail runs on the suspended hosting, the message that would let you recover it arrives in a mailbox that no longer works.
Is two-factor authentication risky?
It is necessary, and it is also the leading cause of permanently losing access at this size, because the second factor lives in a phone that gets lost. What makes the two compatible is one action: print the recovery codes at the moment of activation and put them in the safe. They are shown only once.
What happens if the payment stops going through?
An identical sequence every time: a failure message, reminders, suspension of the service, then much later deletion of the data. It all runs by email, so the real risk is not the card being refused but a contact address nobody reads. Register a second means of payment and note the card’s expiry month.
How long before the data is deleted?
The period exists, is published, and varies a great deal between providers — which is why we do not print one here. Go and find yours once in the terms of service, a quarter of an hour, and write it on the account sheet. Meanwhile hold on to this: suspending is not deleting, and the useful window opens at the moment everybody panics.
Do we need separate accounts for each person?
Yes, and the main account should not be used for daily work: it keeps billing and nothing else. Two concrete benefits — a person leaving is handled by removing their access rather than changing a shared password, and the provider’s logs become readable again. Create the named accounts first, change the main password afterwards.
Where we come in
Look at which address your hosting invoice arrives at. If that mailbox goes unread, you will learn about the cut-off from your own site going quiet.
- We move your services onto a subscription the business itself owns.
- We put two people on the recovery address, never one.
- We hand you the emergency codes and keep none of them.
If the subscription is already owned by the business and two people receive the invoice, keep your money: there is nothing to redo.
Read next
Hosting the model or calling it: what actually decides
The comparison is nearly always drawn between a price per million tokens and the price of a machine. Both figures are true and neither answers the question.Cloud hosting: what costs is not the storage
The line everybody compares is the cheapest on the invoice. The other three get paid on the day you need them most.What you are allowed to send to a model hosted abroad
A chatbot connected to your mailbox exports your customer file, one line at a time. Nobody around the table described it that way.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.