← All components
BlueHive for Employers
https://employer.bluehive.com
Outage
24h uptime
89.19%
7d uptime
97.18%
30d uptime
98.14%
90d uptime
98.14%
Avg latency 24h
338 ms
Status changed
2 hours ago
Last refresh
just now
URL
https://employer.bluehive.com

Response time

Avg total · Avg TTFB · Max totalUTC

Daily uptime (last 90 days)

90 days agoToday

Incident history (last 30 days)

Restoration efforts remain actively underway at our Fort Wayne datacenter.

Our technical teams are currently focused on restoring our edge networking infrastructure, a critical step toward bringing BlueHive services back online. We are making progress and are hopeful that services will begin restoring shortly.

The backup generator remains operational while utility power to the area continues to be impacted by the severe weather.

Multiple technicians and emergency crews continue to work on-site to restore affected infrastructure and services as quickly and safely as possible.

We appreciate your continued patience and will provide another update within 30 minutes, or sooner if there is a significant change in service availability.

criticalInvestigating – Phoenix Datacenter Service Disruption

Thu, 13 Aug 2026 13:56:38 UTC · 50m

All affected checks are reporting up. Incident resolved automatically.

criticalBlueHive Service Incident – July 16, 2026

Thu, 16 Jul 2026 21:56:00 UTC · 9h 10m

BlueHive Incident Report

July 16, 2026 Production Service Interruption

Incident Date: July 16–17, 2026
Status: Resolved
Severity: Major Service Interruption


Executive Summary

On July 16, 2026, at approximately 2:56 PM MST, BlueHive experienced a significant production service interruption affecting customers hosted within our Phoenix production environment.

The incident was initiated by an emergency power event within our colocation facility that resulted in an unexpected loss of power across portions of our production infrastructure. Although electrical service was restored relatively quickly, the event exposed several infrastructure dependencies that complicated recovery, including networking, storage, DNS, and application startup sequencing.

Our engineering team immediately initiated incident response, dispatched personnel onsite to the data center, engaged our colocation provider's facilities and engineering teams, and worked continuously throughout the event to restore customer services while validating infrastructure integrity.

Customer-facing services were fully restored by 12:06 AM MST on July 17.

Most importantly, no customer data was lost or corrupted during this incident.

While the platform has been fully restored, the duration of this outage did not meet our standards. We are conducting a comprehensive engineering review with our colocation provider and implementing several architectural improvements to further strengthen platform resiliency.


Customer Impact

Incident Start

July 16, 2026 – 2:56 PM MST

Service Restored

July 17, 2026 – 12:06 AM MST

Impact

A subset of BlueHive customers experienced:

  • Inability to access the BlueHive platform
  • Delayed or unavailable API requests
  • Delayed order processing
  • Temporary interruption of provider connectivity
  • Intermittent service availability during recovery

No evidence of customer data loss or database corruption was identified during post-recovery validation.


Timeline

2:56 PM

Automated monitoring detected the loss of multiple production systems hosted within the Phoenix environment.

Incident response procedures were immediately initiated while engineering teams began assessing scope and engaging our colocation provider.


3:15 PM

On-site engineers confirmed that multiple infrastructure racks had unexpectedly lost power.

Recovery efforts immediately prioritized restoration of core networking infrastructure including firewalls, switching, virtualization hosts, and storage systems.


4:00 PM

Power began returning to affected equipment.

Although systems were receiving electrical power again, expected network communication did not automatically recover. Engineering efforts shifted from electrical restoration toward infrastructure recovery.


5:30 PM

Engineers isolated several networking conditions preventing infrastructure from communicating after power restoration.

To accelerate recovery while maintaining platform stability, portions of the redundant networking topology were temporarily simplified to establish known-good communication paths.


7:00 PM

Critical infrastructure components including storage clusters, virtualization hosts, DNS services, and networking continued recovering as dependencies were restored.

Customer environments progressively returned online.


9:00 PM

Core application services resumed normal operation as remaining infrastructure dependencies were restored.

Engineering continued validating customer environments while monitoring for residual issues.


12:06 AM

All customer-facing BlueHive services had been restored.

The incident transitioned from recovery into monitoring, validation, and root cause investigation.


Technical Summary

This incident began with an unexpected power disruption originating within our Phoenix colocation facility.

Although electrical service was restored, the power event exposed several independent infrastructure dependencies that significantly extended overall recovery time.

These included:

  • Network redundancy behavior following simultaneous infrastructure power restoration
  • Network configuration inconsistencies identified during recovery
  • Service startup dependencies across DNS, storage, virtualization, and application layers
  • Operational complexity within portions of our redundant networking architecture

No single software defect or hardware failure was responsible for the duration of the outage.

Instead, multiple independent infrastructure recovery conditions combined into a cascading event that required sequential restoration before customer workloads could safely resume.


Power Infrastructure

The Phoenix production environment was intentionally designed with fully redundant power infrastructure.

Each production rack is connected to independent A-side and B-side power distribution units (PDUs). These power paths are expected to remain electrically independent through separate UPS systems, generator systems, breakers, and facility power distribution. The architecture is specifically designed so that the loss of any single electrical path should not interrupt production services.

During this incident, however, systems connected to both redundant power paths experienced an unexpected loss of power.

Based on the architecture of the environment, this should not have occurred.

Because both redundant power paths were simultaneously affected, we have formally escalated the incident with our colocation provider. A joint engineering review is currently underway to validate the physical implementation of the facility's A/B power architecture, confirm complete electrical independence throughout the power distribution chain, and determine why the expected redundancy did not isolate this event.

Until that investigation is complete, we will not speculate on the precise facility-side failure mechanism. However, our expectation is clear: production infrastructure should remain operational through the loss of any single power path, and this event did not meet that expectation.


Why Recovery Took Time

Distributed healthcare platforms are composed of multiple infrastructure layers that depend on one another.

Restoring electrical power represents only the first stage of recovery.

The BlueHive platform relies on coordinated operation of:

  • Power infrastructure
  • Network switching
  • Routing and firewalls
  • Storage clusters
  • DNS services
  • Virtualization hosts
  • Database clusters
  • Application services

Although power returned early in the incident, each layer required validation before dependent services could safely restart.

Rather than rushing application startup, our engineering teams intentionally prioritized platform integrity and data consistency, restoring each layer in sequence before proceeding to the next.

This approach protected customer data while minimizing the risk of additional cascading failures.


What Went Well

Several aspects of our operational response performed exactly as intended.

  • Incident monitoring detected the outage immediately.
  • Engineering personnel responded within minutes.
  • On-site engineers were dispatched directly to the Phoenix facility.
  • Customer data remained fully intact throughout the incident.
  • Storage clusters recovered without data loss.
  • Cross-functional engineering teams worked continuously until all customer environments had been restored.
  • The incident surfaced several infrastructure improvements that are already being implemented.

Opportunities for Improvement

Every production incident provides valuable engineering lessons.

This event highlighted several opportunities to improve the platform.

  • Simplify portions of our network redundancy architecture to reduce recovery complexity.
  • Expand monitoring to include infrastructure dependency validation rather than simple availability checks.
  • Improve automated recovery validation after power events.
  • Increase visibility into configuration drift across network infrastructure.
  • Provide more frequent customer status updates during major incidents.
  • Continue expanding disaster recovery testing under realistic failure scenarios.

Corrective Actions

Several engineering initiatives have already been started as a direct result of this incident.

Infrastructure

  • Complete audit of Phoenix power distribution architecture.
  • Verify true independence of all A/B power feeds.
  • Joint engineering review with the colocation provider.
  • Simplify selected network redundancy components where appropriate.

Monitoring

  • Expand infrastructure dependency monitoring.
  • Implement automated network configuration drift detection.
  • Improve topology validation and interface monitoring.
  • Increase visibility into startup dependencies following infrastructure failures.

Operations

  • Enhance disaster recovery validation procedures.
  • Improve deployment and operational documentation.
  • Standardize incident communications with scheduled customer updates.
  • Increase automation around infrastructure recovery validation.

These improvements are already underway and will continue over the coming weeks.


Closing

BlueHive is trusted to support critical occupational health workflows, and we recognize the responsibility that comes with that trust.

While no production platform can eliminate every possible failure scenario, every incident should make the platform stronger than it was before.

This event challenged several assumptions about our infrastructure and recovery processes. The findings are already driving meaningful improvements across our power architecture, networking, monitoring, automation, and operational procedures.

We sincerely apologize for the disruption and appreciate the patience and professionalism our customers demonstrated throughout the incident. Our commitment remains unchanged: to deliver a resilient, secure, and highly available platform that healthcare providers and employers can depend on every day.