Theme
Status and incidents
Where to look, in order
| Question | Look at |
|---|---|
| Is the platform having a problem right now? | sftpcloud.online |
| Is my site up, and is my storage reachable? | Your site's Overview in the Portal |
| Was last month's availability what we promised? | Service level |
| Did something change on my account? | Activity |
| Who did what to which file? | Your Connector's Activity |
The public status page
It needs no sign in, and it works when the Portal does not.
It reports two things:
- Portal. Sign in, your account, and the management console.
- Transfer service. SFTP, FTPS and the web client.
Each carries a badge and a bar of the last hour, one tick per minute.
| Badge | Meaning |
|---|---|
| Operational | Answering. Where an aggregate wording applies to the transfer fleet, that word appears instead |
| Not answering | The monitors agree it is down |
| Not measured | No usable measurement for that moment |
Why it is on a different domain
The page is on its own registrable domain, at a different registrar, on different DNS, on different hosting, from the platform it reports on. It shares nothing with what it measures.
A status page hosted by the thing it reports on goes down with it, exactly when it is needed.
There is deliberately no status.sftp.cloud, because that name would reintroduce the dependency at the address most people would type.
Who measures it
Independent monitors, on hosting we do not share with the service they measure, placed so that no one hosting provider holds a majority and the provider hosting the measured service holds the minority.
A minute resolves only when enough of them agree.
The one sentence worth understanding
When fewer than the required number of monitors are reporting, the page says it cannot confirm platform status.
That is not an outage. It means the measurement is incomplete and the page will not guess. It says nothing about whether the service is up.
What the page will not tell you
- A percentage. The bar shows the shape of an hour, not a number to read off.
- Your site specifically. It reports the platform, not one customer's site.
- Your Connector. That is on your own network.
Your site's own status
Your site's Overview page separates two things on purpose:
Our platform. The services we run for you, covered by the service level agreement.
Your connectors. Reachability of the Storage Connectors on your own network. This is not part of the service level agreement, because it is not ours.
When your Connector is unreachable, transfers stop and the platform is fine. The page says which is which so you are not filing a ticket with us about your own network, or the other way around.
A site you paused with Be right back reads as Be right back, not as down; nothing about it is an incident.
During an incident
Check the status page first. If it shows a problem, we already know.
If it does not, and your site is affected, that is worth telling us: open a ticket from Get help. A problem affecting one site is invisible on a platform status page by design.
If the Portal itself is unreachable, email scsp@support.sftp.cloud.
Afterwards
Availability is measured for every calendar month, published for every calendar month including the good ones, and credited automatically when it falls below what we commit to.
There is nothing to claim, no form to file and no deadline to miss. See Service level.
Planned work by us is excluded from the figure, listed with its date, its length and a plain sentence saying what it was.
Holding us to it
Two mechanisms exist so that none of the above depends on trusting us:
The measurements are independent. The monitors are not our infrastructure grading its own homework, and the status page is served from storage outside our platform.
Our own log's position is published openly at /api/v1/transparency/log on the Portal, with no sign in required. Record what it says from time to time and keep it alongside your own evidence. See Tamper evidence.