Static site uptime is not a number anyone publishes, and this post will not invent one. What can be said honestly is structural: a static site on a CDN has fewer independent parts than a database-backed application, and fewer parts is fewer things that can fail. What matters is what each architecture does when something goes wrong, not a percentage nobody has measured.
What can actually break on a static site?
A static site depends on four things: your DNS provider, the CDN serving the built files, the build pipeline turning source into pages, and the git host holding that source. None is a process you have to keep alive yourself. There is no application to crash, no database connection to drop, no background job to stop running. If the CDN is up and DNS resolves, the pages people are reading keep being served, already built and sitting on disk close to the visitor.
That is a genuinely short list, and not zero. A CDN provider has its own outages, DNS providers have theirs, and a git host going down can stop you shipping a fix even though the live site is untouched. Static removes the parts a small team would otherwise run, not every point of failure in the chain.
What can actually break on a self-run server?
Everything on the static list, plus a second, longer list that exists only because something runs continuously. The application process can crash or hang. The database can run out of connections or disk, or need an unscheduled restart. The host needs its own patching, and an auto-renewing certificate can fail without anyone noticing until a browser refuses the page. Fider, one of the best-known self-hosted feedback tools, documents Docker and PostgreSQL 12 or later as requirements, and its release history shows what running it yourself means: three security fixes within three months, v0.35.0 for a critical authentication vulnerability, v0.36.0 for server-side request forgery and cross-site scripting, v0.36.1 for further security work. The operator has to notice each one and redeploy before someone else finds the gap first.
This is not an argument that self-hosting is a mistake. It is that it is a different job: everything a static site depends on, plus a process, a database, a disk and a certificate now yours to watch.
What can actually break on a hosted SaaS tool?
Their infrastructure, in full, and you will not know which part until they tell you, if they tell you. Paying someone else to run it means a shorter list than your own self-run server, since it is their full-time job, but no visibility and no lever to pull. You cannot restart their process or see their status page update before your customers do. You wait.
| Architecture | What can fail | Who can act on it |
|---|---|---|
| Static site on a CDN | DNS, the CDN, the build pipeline, the git host | You, little is continuously running |
| Self-run server | All of the above, plus the process, the database, the disk, the host, the certificate | You, and you must notice first |
| Hosted SaaS tool | Their infrastructure, entirely | Nobody on your side, until they act |
What does an SLA actually promise?
Not uptime. An SLA is a contract for what you get back if a published availability target is missed, normally a partial refund or a service credit, not your board coming back online faster. Jira Product Discovery lists a 99.9 per cent uptime SLA with service credits on Atlassian's own page as Premium-only, at $25 per creator per month; Free and Standard carry no such commitment. Nolt.io offers the same 99.9 per cent uptime SLA only on its top Enterprise tier.
Put plainly, an SLA is a paid add-on that compensates after the fact. It does not restore your board while customers are looking at it, and a small credit against next month's invoice does nothing for the reader who cannot file a bug report right now.
Why does a static site tend to fail stale rather than down?
Because most static hosts keep serving the last successful build if a new one fails. Nothing stops your build pipeline from breaking, and it will, at some point. What changes is the consequence: the pages already live keep being served exactly as they were, because no process needs to restart and no deploy has to succeed for the site to keep answering requests. The visitor gets yesterday's roadmap rather than no roadmap.
That is a real advantage and a real cost together. Stale is a gentler failure than dark for most of what a support site carries: an old changelog entry is still true, a vote count a few minutes behind is still roughly right. It is a worse failure for the one piece of content where freshness is the whole point, a status update during an actual incident, where the honest worst case is "still showing the old status", not "definitely showing the current one".
One payment, no subscription, unlimited products.
So which failure profile do you actually want?
None of the three architectures is free of risk, they carry different ones. Static trades a shorter list of moving parts for a dependency on your build pipeline and git host, with a worst case usually staleness rather than an outage. A self-run server gives full control and full responsibility for the process, database and certificate, on top of what static already depends on. A hosted tool gives someone else's full-time attention, in exchange for no lever of your own, and an SLA, where one exists, that pays you back rather than fixes anything.
Docket is a static site plus two small endpoints, for the reasons worked through in static site or server: most of a feedback tool is reads, and reads fail gently. That does not make it correct for every team, only one answer worth weighing structurally rather than settling with a number nobody has published.
The wider self-hosting decision, hours and running cost included, is in self-hosting a feature request board, broken down further for this shape in what a self-hosted support centre costs. Every server-backed open-source option, licence and activity, is compared in the open source options compared.
Frequently asked questions
Is static site uptime actually better than a hosted SaaS tool's?
Nobody in this category publishes a number for either side, so this cannot be answered with a percentage. Structurally, a static site depends on fewer continuously running parts than a self-run server or a hosted application, so there is less that needs to keep working for the pages to load. Whether that means fewer real outages over a year is not something this page can honestly claim to know.
What does an uptime SLA actually guarantee?
A refund or a service credit if a published availability target is missed, not faster recovery. Jira Product Discovery's 99.9 per cent SLA sits behind its Premium tier only, and Nolt.io's 99.9 per cent SLA sits behind its top Enterprise tier. Read an SLA as compensation for downtime, not protection against it.
What is the most common thing that actually goes wrong with a self-hosted feedback tool?
Patching, mostly, and it is not hypothetical. Fider shipped three separate security fixes inside three months, including one for a critical authentication vulnerability. Running your own server means noticing each release and redeploying, on top of the database, disk and certificate upkeep any long-running application carries.
Can a static site still go down?
Yes. It depends on DNS resolving, its CDN being up, and its build pipeline and git host working when a change ships. A CDN or DNS outage takes a static site offline exactly as anything else. What static removes is the layer of failures that exist only because a process runs continuously: no application to crash, no database to run out of connections, no certificate job to silently fail.
Does Docket carry an uptime SLA?
No, and it does not need the infrastructure an SLA is usually written to compensate for. Docket builds as static files plus two small endpoints, so there is no application process or database of its own to keep alive. Uptime then depends mostly on your chosen static host, CDN, DNS and git host, the same as any other static site. Check your host's own status history rather than take a figure on trust from any vendor, including this one.