What is Webroot's uptime?

Over the last 90 days, Webroot reported 99.38% uptime on its official status page. That figure is calculated from the public incident timeline at https://status.webroot.com — each minute of degraded, partial-outage, or major-outage status counts against the total. Sign up to Pingoru free to see Webroot's uptime history rolling forward in real time.

Has Webroot had outages in 2026?

Yes — Webroot has had 247 incidents reported on its official status page so far in 2026. The full timeline (start times, durations, components affected) is shown above on this page. Pingoru re-checks the status page every 5 minutes so the count stays current.

When was the last Webroot outage?

The most recent Webroot incident was "São Paulo BR14 was experiencing service degradation.", which started on July 31, 2026 and was resolved on July 31, 2026. Pingoru captured this directly from https://status.webroot.com. See the full incident card above for affected components and the update timeline.

How often does Webroot have outages?

Based on the last 90 days, Webroot averages 82.3 reported incidents per month on its official status page. Pingoru tracks each one with start time, duration, severity, and affected components — so you can see the pattern at a glance instead of digging through the vendor's archive.

Where is Webroot's status page?

Webroot's official status page is https://status.webroot.com. Pingoru polls it every 5 minutes and renders the same data here, alongside every other cloud or SaaS provider you depend on — so you can spot multi-vendor incidents (e.g. AWS + Stripe + Cloudflare degrading at the same minute) without flipping between tabs.

Is Webroot down right now?

Webroot is down. Pingoru checks the official status page every 5 minutes and flips this headline the moment Webroot reports a change. Current status is based on 264 tracked services.

How does Pingoru know if Webroot is down?

We read https://status.webroot.com directly, using Webroot's own status page. If the vendor reports an incident, you see it within one check cycle — not after someone manually marks the page as down.

Where can I get notified when Webroot has an outage?

Create a free Pingoru account and add Webroot as a monitor. You can filter to specific services, pick severity thresholds, and route alerts via email, Slack, Discord, or a webhook.

Webroot's status page says the service is up, but I'm having issues — what's wrong?

Three common reasons: • A real Webroot incident that hasn't been acknowledged on their public status page yet — vendor status pages are updated manually and typically lag the first customer reports by 10–30 minutes. • A regional or account-scoped issue affecting a subset of customers — these rarely trigger a global status-page change. • A local problem: ISP / DNS / your own software. Try reproducing from a mobile data connection and from a different network to isolate. If you suspect a real Webroot issue that isn't reflected yet, contact their support to escalate. Subscribing here means you get the alert the moment they do post an update.

Where does Pingoru get the official Webroot status?

We use Webroot's own status page at https://status.webroot.com. Nothing is read in a way the vendor hasn't explicitly made public — we use the same data their own dashboard uses. So our data is as accurate as what you'd see loading the status page yourself, but rolled into one dashboard alongside every other service you depend on.

What does "Major Outage" mean?

Webroot is reporting a major outage. A significant portion of the service is unavailable.

Is Webroot down?

Last checked 8m ago

Current status

Webroot is down

3 active incidents: Threat Intelligence (BrightCloud) - Frankfurt Database Main…, Core Endpoint Backup Red-APAC Vault Application Maintenance… · +1 more

Get alerts when Webroot breaks → View Webroot outage history →

Free · no credit card

Official status page: https://status.webroot.com · Polled every 5 minutes · 264 components tracked

Webroot is reporting a major outage right now (last checked 8m ago). 3 active incidents on the official status page.

Real-time Webroot status, recent outages, and incident history — pulled directly from Webroot's official status page at https://status.webroot.com every 5 minutes. Pingoru tracks 264 Webroot services and has captured 250 incidents in the last 90 days (99.38% uptime). Get email, Slack, Discord, or webhook alerts the moment Webroot reports a new incident — free for 5 monitors, no credit card.

Users who monitor Webroot also follow these Security services:

Keeper View all 6,000+ providers

Webroot uptime 99.38% uptime · past 90 days

Mon Wed Fri

MayJunJul

Less More

Active incident 1

Middle East ME22 is experiencing an outage

Ongoing ● 70d 16h

Started May 21, 2026, 04:57 PM UTC

Middle East ME22
Timeline · 3 updates
- investigating · May 21, 2026, 04:57 PM UTC
  
  Middle East ME22 is currently unavailable due to regional conditions in the Middle East. We sincerely apologize for any inconvenience this may cause. Updates for this issue will be posted as soon as there are significant updates. We appreciate your patience.
- investigating · Jun 23, 2026, 02:07 PM UTC
  
  Middle East ME22 is currently unavailable due to regional conditions in the Middle East. We sincerely apologize for any inconvenience this may cause. Updates for this issue will be posted as soon as there are significant updates. We appreciate your patience.
- investigating · Jul 27, 2026, 04:08 PM UTC
  
  Middle East ME22 is currently unavailable due to regional conditions in the Middle East. We sincerely apologize for any inconvenience this may cause. Updates for this issue will be posted as soon as there are significant updates. We appreciate your patience.
Latest: Middle East ME22 is currently unavailable due to regional conditions in the Middle East. We sincerely apologize for any inconvenience this may cause. Updates for this issue will be…

Recent outages & incidents

Past 90 days

São Paulo BR14 was experiencing service degradation.

Resolved —

Started Jul 31, 2026, 04:43 AM UTC · Resolved Jul 31, 2026, 04:43 AM UTC

São Paulo BR14
Timeline · 1 update
- resolved · Jul 31, 2026, 04:43 AM UTC
  
  São Paulo BR14 experienced performance and functionalities degradation in service. The issue is now resolved. We appreciate your patience. Tracking Number: IM3971517
Latest: São Paulo BR14 experienced performance and functionalities degradation in service. The issue is now resolved. We appreciate your patience. Tracking Number: IM3971517
Zix - Customer Portal incorrectly authentication issue

Resolved 1d

Started Jul 28, 2026, 05:31 PM UTC · Resolved Jul 29, 2026, 05:38 PM UTC

Zix Customer Portal Interface - Customer Portal
Timeline · 3 updates
- identified · Jul 28, 2026, 05:31 PM UTC
  
  We are currently investigating reports of partners incorrectly authenticating through the Customer Portal with incorrect log ins. Our team is actively triaging this issue now. Incident: IM3969646
- monitoring · Jul 28, 2026, 05:38 PM UTC
  
  We have successfully initiated a rollback that caused this authentication issue and have confirmed the issue no longer is ouccring. We are continuing to actively monitor our logs to ensure everything is fully operational. Incident: IM3969646
- resolved · Jul 29, 2026, 05:38 PM UTC
  
  This incident has been resolved.
Latest: This incident has been resolved.
Oregon US6 experienced intermittent service unavailability

Resolved 1h 33m

Started Jul 27, 2026, 02:21 PM UTC · Resolved Jul 27, 2026, 03:54 PM UTC

Oregon US6
Timeline · 4 updates
- investigating · Jul 27, 2026, 02:21 PM UTC
  
  Oregon US6 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968671
- investigating · Jul 27, 2026, 03:22 PM UTC
  
  Oregon US6 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968671
- resolved · Jul 27, 2026, 03:54 PM UTC
  
  Oregon US6 experienced intermittent service unavailability. The issue is now resolved. We appreciate your patience. Tracking Number: IM3968671
- postmortem · Jul 29, 2026, 05:30 PM UTC
  
  **Interim Root Cause** **Tracking number:** IM3968671 PM1011655 **Incident windows:** July 27, 2026, from 13:28 GMT to 14:15 GMT **Services affected:** OpenText™ Enterprise Service Management \(ESM US6\) **Overview** On July 27, 2026, at 14:11 GMT, Incident Management was engaged to investigate intermittent availability and performance degradation in the US6 environment. **Impact** Clients experienced degraded service performance, resulting in slow user interface \(UI\) response times. **Root Cause** The root cause analysis identified two primary contributing factors: • RabbitMQ Metadata Store Instability: An instability within the RabbitMQ Metadata store caused inconsistencies in queue metadata, resulting in messaging disruptions across the platform. • Connection Recovery Failures: Certain application services were unable to automatically re-establish stable RabbitMQ connections after failures, leading to degraded platform performance and functionality. **Resolution** The investigation revealed that insufficient replica capacity in Gateway and Platform services was impacting service performance. The number of replicas for both services was increased, and the service was restored. Full validation was completed by 14:15 GMT, ending the impact. **Action Plan** Engineering teams continue to investigate the underlying root cause of this incident and identify additional corrective and preventive measures to reduce the risk of recurrence. As part of the remediation effort, a long-term stability improvement program has been launched to enhance RabbitMQ resilience, strengthen application connection recovery mechanisms, and expand proactive monitoring and alerting capabilities. These improvements, along with enhancements planned for Release 26.3.1, are expected to further improve system stability and significantly reduce the likelihood of similar incidents in the future. OpenText took the following actions and will determine additional preventative actions as needed. ‌ • Implemented static pod assignment for RabbitMQ, replacing dynamic allocation to reduce the risk of pod contention. - **COMPLETE** • Increased CPU resources allocated to RabbitMQ pods to alleviate performance bottlenecks and improve overall system stability. - **COMPLETE**
Latest: **Interim Root Cause** **Tracking number:** IM3968671 PM1011655 **Incident windows:** July 27, 2026, from 13:28 GMT to 14:15 GMT **Services affected:** OpenText™ Enterprise Service…
Frankfurt EU8 experienced intermittent service unavailability.

Resolved 2h 39m

Started Jul 27, 2026, 09:03 AM UTC · Resolved Jul 27, 2026, 11:42 AM UTC

Frankfurt EU8
Timeline · 5 updates
- investigating · Jul 27, 2026, 09:03 AM UTC
  
  Frankfurt EU8 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968415
- monitoring · Jul 27, 2026, 09:48 AM UTC
  
  Frankfurt EU8 experienced intermittent service unavailability. Service has been restored and is now being validated. We appreciate your patience. Tracking Number: IM3968415
- monitoring · Jul 27, 2026, 10:54 AM UTC
  
  Frankfurt EU8 experienced intermittent service unavailability. Service has been restored and is now being validated. We appreciate your patience. Tracking Number: IM3968415
- resolved · Jul 27, 2026, 11:42 AM UTC
  
  Frankfurt EU8 experienced intermittent service unavailability. The issue is now resolved. We appreciate your patience. Tracking Number: IM3968415
- postmortem · Jul 29, 2026, 02:26 PM UTC
  
  **Interim Root Cause** **Tracking number:** IM3968415 PM1011655 **Incident windows:** July 27, 2026, from 06:31 GMT to 09:41 GMT **Services affected:** OpenText™ Enterprise Service Management \(ESM EU8\) **Overview** On July 27, 2026, at 07:10 GMT, Incident Management was engaged to investigate intermittent access issues and service unavailability. **Impact** Several clients experienced intermittent access issues and service unavailability across the ESM EU8 environment. **Root Cause** The root cause analysis identified two primary contributing factors: • RabbitMQ Metadata Store Instability: An instability within the RabbitMQ Metadata store caused inconsistencies in queue metadata, resulting in messaging disruptions across the platform. • Connection Recovery Failures: Certain application services were unable to automatically re-establish stable RabbitMQ connections after failures, leading to degraded platform performance and functionality. **Resolution** The CPU allocation was increased, and the RabbitMQ queues were rebalanced to improve system stability and performance. Systematic restarts of the platform pods were completed at 07:56 GMT, which restored the core services. However, the SLT service continued to experience issues. The cluster was rebuilt, and services normalized at 09:41 GMT. Additional manual checks were completed across the environment to clear false degradation alerts, and no further issues were observed. Validations were completed at 11:38 GMT, ending the impact. **Action Plan** Engineering teams continue to investigate the underlying root cause of this incident and identify additional corrective and preventive measures to reduce the risk of recurrence. As part of the remediation effort, a long-term stability improvement program has been launched to enhance RabbitMQ resilience, strengthen application connection recovery mechanisms, and expand proactive monitoring and alerting capabilities. These improvements, along with enhancements planned for Release 26.3.1, are expected to further improve system stability and significantly reduce the likelihood of similar incidents in the future. OpenText took the following actions and will determine additional preventative actions as needed. ‌ • Implemented static pod assignment for RabbitMQ, replacing dynamic allocation to reduce the risk of pod contention. - **COMPLETE** • Increased CPU resources allocated to RabbitMQ pods to alleviate performance bottlenecks and improve overall system stability. - **COMPLETE**
Latest: **Interim Root Cause** **Tracking number:** IM3968415 PM1011655 **Incident windows:** July 27, 2026, from 06:31 GMT to 09:41 GMT **Services affected:** OpenText™ Enterprise Service…
Frankfurt EU8 is currently experiencing intermittent service unavailability

Resolved 1h 1m

Started Jul 27, 2026, 07:17 AM UTC · Resolved Jul 27, 2026, 08:19 AM UTC

Frankfurt EU8
Timeline · 2 updates
- investigating · Jul 27, 2026, 07:17 AM UTC
  
  Frankfurt EU8 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968415
- resolved · Jul 27, 2026, 08:19 AM UTC
  
  Frankfurt EU8 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968415
Latest: Frankfurt EU8 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking N…

See the full Webroot outage history

67 more incidents in the last 90 days, plus the full multi-year archive of per-service events and update timelines.

Browse Webroot outage history →

Or sign up free to get alerts when Webroot breaks · 10 free monitors · No credit card

Outage history

Past 90 days · 72 incidents View full outage history →

São Paulo BR14 was experiencing service degradation. Resolved

Started Jul 31, 2026, 04:43 AM UTC · Resolved Jul 31, 2026, 04:43 AM UTC · —
Zix - Customer Portal incorrectly authentication issue Resolved

Started Jul 28, 2026, 05:31 PM UTC · Resolved Jul 29, 2026, 05:38 PM UTC · 1d
Oregon US6 experienced intermittent service unavailability Resolved

Started Jul 27, 2026, 02:21 PM UTC · Resolved Jul 27, 2026, 03:54 PM UTC · 1h 33m
Frankfurt EU8 experienced intermittent service unavailability. Resolved

Started Jul 27, 2026, 09:03 AM UTC · Resolved Jul 27, 2026, 11:42 AM UTC · 2h 39m
Frankfurt EU8 is currently experiencing intermittent service unavailability Resolved

Started Jul 27, 2026, 07:17 AM UTC · Resolved Jul 27, 2026, 08:19 AM UTC · 1h 1m
Frankfurt EU8 experienced an issue Resolved

Started Jul 26, 2026, 04:15 PM UTC · Resolved Jul 26, 2026, 04:15 PM UTC · —
Zix Hosted Exchange/Customer Portal not saving updates to user settings Resolved

Started Jul 25, 2026, 09:57 PM UTC · Resolved Jul 27, 2026, 01:08 PM UTC · 1d 15h
Cloud Fax services North America experienced issues Resolved

Started Jul 24, 2026, 03:05 PM UTC · Resolved Jul 24, 2026, 03:05 PM UTC · —