Uptime for the last six months was 99.95%.

As of May 1, 2018. We track uptime using Pingdom testing at at a one-minute resolution as well as monthly uptime stats live at

UserVoice assets and widgets load quickly from anywhere in the world.

All static files (JS, CSS, widgets, images) are compressed and served from our CDN (Cloudflare), which has edge servers located around the world.

UserVoice widgets will not impact your page load times.

UserVoice widgets are written in such way that they won‘t block page load and instead only load after the initial page is loaded. This means that your page load times are not impacted by installation of any UserVoice widget.

Network-level redundancy.

Provided by the Google Cloud Platform.

Application-level redundancy.

  • Redundant front-end proxy web servers.
  • Behind them are multiple application servers sitting behind a load balancer that ensures that if a server goes offline requests are immediately funneled to the remaining servers.
  • Database is arrayed in a standard master-slave configuration to provide a live backup and failover database should the master database server go offline.
  • Redundant secondary data stores.
  • Application is hosted in multiple availability zones to protect against downtime.

Internal as well as external monitoring means we respond quickly to any service issues.

  • Internal system monitoring tools (Consul health check) check on all systems every five minutes, and critical systems or errors are checked every minute.
  • Any critical errors (ex: server offline) triggers SMS alerts to the entire systems engineering team.
  • Pingdom is used to both monitor uptime of UserVoice sites as well as our internal tools (Consul health check). The watcher of the watchers, if you will.
  • Application level monitoring includes custom internal tools (based on statsd) to track application events, tracking all 500 errors (failed requests) using Bugsnag and New Relic APM to track error rates and response times.
  • A critical issue policy is followed to ensure that proper issue escalation occurs. After any critical incident (defined as any incident that impedes end-users from performing core functionality), engineering is required to provide a write-up and retrospective on what went wrong and how it can be prevented in the future. These write-ups are often shared with customers via
  • Real-time notifications about any current service delivery issues are available at