Is Monnit down?

we are investigating a database issue.

We identified the issue with logs pending update to primary datacenter. we’ve restored services, and are continuing work to finalize the fix.

Service Outage: October 11, 2026 What happened, what we did, and what comes next Date - October 11, 2026 How long - About 100 minutes (12:25 PM to 2:05 PM Mountain Time) Who was affected - All users Status today - Service is fully restored. One behind-the-scenes task is still in progress (see below). What happened On the afternoon of October 11, our services were unavailable because the database could not accept new transactions. The transaction log reached capacity, pending restoration of our primary database pair from the October 5 issue. We were able to dissolve the Distributed Availability Group (DAG) between data centers and expand the transaction log size to allow processing. We have since run new full backups and transaction log backups and verified all databases are clearing the log with the transaction log backups as expected. Why it happened Following the outage on October 5, the transaction log backups were verified, and we started planning a maintenance window to bring the other database pair online. It was not noticed that the transaction log backups were not clearing the log because the inactive database pair in the DAG was offline. Once the log reached the allotted disk capacity, further transactions were blocked. How we fixed it Our team dissolved the DAG so that transaction log backups could clear the transaction log. We also temporarily expanded the disk capacity for the transaction logs. That permitted the database to process new transactions. After that we ran full backups and log backups and ensured that all databases are properly clearing the transaction log files. What is still in progress Our services are running using the database servers in the backup data center. Our main data center’s databases still need to be reconnected and resynchronized. While that is being done, we still have a pair of servers running to provide high availability. We plan to finish this during a scheduled maintenance window, which is expected to cause little or no downtime. What we are doing to prevent this Updating our policy for managing DAG outages. Evaluating alerts that warn us when the log is close to full. Timeline 12:25 PM - Transaction log hit capacity. 1:30 PM - Distributed Availability Group dissolved. 1:45 PM - Transaction log disk limits expanded. 2:05 PM - Restarted connected applications, restoring service.

We are currently investigating a service outage.

We have failed over to our secondary datacenter and services are online. We are continuing the investigation with our primary datacener.

Primary Datacenter web and app servers have been restored. Database is still running in secondary datacenter without full redundancy while our administrators work to restore full redundancy.

Resolved

Service Outage: October 5, 2026 What happened, what we did, and what comes next Date October 5, 2026 How long - About 68 minutes (3:05 PM to 4:13 PM Mountain Time) Who was affected - All users Status today - Service is fully restored. One behind-the-scenes task is still in progress (see below). What happened On the afternoon of October 5, our services went offline at our main data center. The PDU (Power Distribution Unit) in our cabinet overloaded and tripped one of the breakers. When the load was transitioned to the backup power leg, the same breaker on that PDU also tripped. This caused a loss of power for our network equipment. We moved our services to our backup data center, and they were back online about an hour later. Why it happened The electrical system in the data center was carrying an uneven load, with too much demand on one circuit. That circuit overloaded and shut off, which cut power to the equipment that connects our systems to the internet. The facility has two separate power paths allowing the backup to take over if the primary fails. In this case, both were overloaded, one after the other. Resulting in the redundant power path not being able to prevent the outage. How we fixed it Our team switched services over to the backup data center, which restored service at 4:13 PM. Technicians then went to the main data center, checked that our data was safe, evened out the electrical load, and turned the power back on. By 5:05 PM our servers in the main data center were running again. What is still in progress Our services are running using the database servers in the backup data center. Our main data center’s databases still need to be reconnected and resynchronized. While that is being done, we still have a pair of servers running to provide high availability. We plan to finish this during a scheduled maintenance window, which is expected to cause little or no downtime. What we are doing to prevent this Reviewing the electrical load at both of our data centers and evening it out. Evaluating real-time alerting to warn us when power usage gets too high, before anything shuts off. Timeline 3:05 PM - Connection to the main data center was lost. 3:57 PM - Working with an onsite data center technician, we determined the network equipment had no power and could not be powered on. We began the failover to the backup data center. 4:13 PM - Services were back online from the backup data center. 4:50 PM - Our technicians reached the main data center, found the cause, and restored power. 5:05 PM - Servers at the main data center were running again.