Service status

Flowtly publishes a status page at status.flowtly.eu. It answers one question, without you having to write to anyone: is Flowtly working, or is the problem at our end?

The page is hosted separately from the Flowtly application, so it stays up when Flowtly does not. That separation is the whole point — a status page that fails alongside the thing it reports on cannot tell you anything at the moment you actually need it.

What the page shows

At the top is a single headline answer for Flowtly as a whole. Below it is a row for each part of Flowtly that can fail on its own — the workspace you sign in to, the API that integrations and the mobile app use, e-invoicing, bank synchronisation, email and notifications, and the AI surfaces, among others. Each row shows that part's current state, and a bar for each of the last 90 days so you can see whether today is unusual.

A row reads as one of the following:

• Operational — the automated check is passing.
• Degraded — the part is responding, but slowly or only partially.
• Down — it is not responding.
• Unknown — the check could not be completed, so nothing is being claimed about that part.
• Not monitored — no automated check watches that part yet.

The last two are worth reading carefully, because both mean we cannot tell you, for different reasons. Unknown means a check ran and did not come back; the page deliberately shows that rather than green, because a check that failed is not evidence that everything is fine. Not monitored means nothing is measuring that part at all — it is listed anyway, so that you can see it is unmeasured instead of assuming it is healthy.

If the page itself cannot load its data, it says so and shows nothing reassuring. A page that reports "everything is fine" when it has not managed to check is worse than one that admits it does not know.

Incidents and updates

Below the component rows is a timeline of incidents. State changes and their times are recorded automatically, from the same checks that drive the rows above.

An entry labelled Update from our team is different: it is written by a person, about something the automated checks cannot see. Everything else on the timeline is machine-recorded. The label exists so that you can tell the two apart — a measurement and an explanation are not the same kind of statement, and the page does not present one as the other.

Because a person writes them, these updates are also where you will find context an automated check has no way to produce: what is affected, and what is being done about it.

Sometimes such an update appears above the component rows instead, on its own. That happens when we know about something the automated checks cannot see — a delay at a service Flowtly depends on, for instance, where every check we run still passes. The component states below it stay as they are measured, and the update tells you the part that could not be measured. Both are on the page because neither one alone is the whole answer.

Getting told instead of checking

There are two ways, and neither of them requires you to remember to look.

By email. Enter your address on the status page and you will be sent a confirmation message. You are not subscribed until you open that message and click the link in it. The confirmation link stays valid for seven days; if it lapses before you use it, subscribe again from the page and a fresh one is sent. You are told when something breaks and again when it is fixed.

By feed. The page also publishes an Atom feed, linked at the bottom of it. A feed asks nothing of you — no address, no confirmation — and most chat and monitoring tools can subscribe to one directly, so incidents can land in the channel your team already watches rather than in one more inbox.

Each incident is one entry in the feed, updated when it opens and when it resolves. It does not repost itself every time a detail changes, so subscribing to it does not turn into a stream you learn to ignore.

When the page says everything is fine and it is not

The status page reports on Flowtly as a whole. A problem affecting a single account or a single organisation is not an outage, and it will not show up there.

So if something is not working for you while the page reports normal service, that is worth telling us about rather than waiting: write to support@flowtly.eu.

Reading the page in Polish

The status page is available in Polish at status.flowtly.eu/?lang=pl. The language you pick stays in the address, so a link shared during an incident opens in the language it was written in.

Example use cases

• Invoices stopped arriving: Check the row for e-invoicing and for email and notifications before assuming the problem is in your own setup.
• A bank feed has not updated: See whether bank synchronisation is degraded, and whether the timeline already records an incident covering it.
• You cannot sign in: Check the workspace row — if it reports normal service, the cause is more likely to be your account or your network than an outage.
• Telling your team what is happening: Share the status page link rather than relaying updates yourself, so everyone reads the same thing at the same time.
• Staying ahead of it: Subscribe to email updates so that an incident reaches you before a colleague does, or point your team's chat tool at the feed so it lands where people already are.