Monnit Outage History

Started Oct 11, 2026, 07:04 PM UTC· resolved Oct 11, 2026, 08:22 PM UTC

1. investigating Oct 11, 2026, 07:04 PM UTC

   we are investigating a database issue.

2. resolved Oct 11, 2026, 08:22 PM UTC

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

3. investigating Oct 12, 2026, 01:50 PM UTC

   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.

Read the full incident report →

Started Oct 05, 2026, 09:20 PM UTC· resolved Oct 06, 2026, 03:00 AM UTC

1. investigating Oct 05, 2026, 09:20 PM UTC

   We are currently investigating a service outage.

2. investigating Oct 05, 2026, 10:15 PM UTC

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

3. identified Oct 06, 2026, 12:47 AM UTC

   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.

4. resolved Oct 06, 2026, 03:00 AM UTC

   Resolved

5. investigating Oct 08, 2026, 10:01 PM UTC

   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.

Read the full incident report →

Started Apr 03, 2026, 04:44 PM UTC· resolved Apr 03, 2026, 08:01 PM UTC

1. investigating Apr 03, 2026, 04:44 PM UTC

   We are investigating a service disruption affecting all production services.

2. monitoring Apr 03, 2026, 05:15 PM UTC

   We were able to get the secondary database node to take over processing. We’re monitoring that, and still evaluating root cause.

3. resolved Apr 03, 2026, 08:01 PM UTC

   All services restored

Read the full incident report →

Started Mar 17, 2026, 06:55 PM UTC· resolved Mar 17, 2026, 10:42 PM UTC

1. investigating Mar 17, 2026, 06:55 PM UTC

   We are investigating an issue in the database synchronization that is causing service disruption.

2. resolved Mar 17, 2026, 10:42 PM UTC

   DB synchronization error has been remedied by ejecting the unhealthy node. There are still multiple active nodes processing data. The ejected node will be evaluated resolved and added back in later.

Read the full incident report →

Started Mar 17, 2026, 02:00 PM UTC· resolved Mar 17, 2026, 10:00 PM UTC

1. completed Mar 17, 2026, 10:00 PM UTC

   Dear Customer, We would like to inform you of a scheduled infrastructure update for the monitoring platform. Maintenance Date: March 17, 2026 Start Time: 10:00 AM Eastern Time Estimated Duration: Up to 8 hours During this maintenance window, we will migrate to a cloud load balancer to improve redundancy and long-term platform stability. Most customers will not need to take any action. However, organizations that restrict outbound traffic by IP address must update their firewall rules to ensure uninterrupted device communication. Please ensure the following IP addresses are allowed. Gateway Traffic (Outbound Port 3000): 166.117.35.68 166.117.206.175 Website Traffic (Outbound Ports 80 and 443): 44.241.242.96 44.228.29.168 If your organization restricts outbound communication by IP address, please ensure these addresses are added to your allow list prior to the maintenance window. If you are unsure whether your network restricts outbound traffic, please forward this notice to your IT or networking team. If you have any questions or need assistance, please contact our support team. Thank you for your continued partnership. Best regards, Support Team

Read the full incident report →

Started Feb 21, 2026, 07:02 PM UTC· resolved Feb 21, 2026, 09:00 PM UTC

1. investigating Feb 21, 2026, 07:02 PM UTC

   Service outage under investigation

2. resolved Feb 21, 2026, 07:16 PM UTC

   Database transaction log issue resolve. Services back online

3. identified Feb 21, 2026, 07:25 PM UTC

   Transaction Log blocking commits

4. monitoring Feb 21, 2026, 07:54 PM UTC

   Administrators indicating resolution will be completed within an hour.

5. resolved Feb 21, 2026, 09:00 PM UTC

   All services online

6. investigating Feb 24, 2026, 02:21 PM UTC

   During routine certificate renewals, one certificate was inadvertently not upgraded. This certificate was associated with the backup process. Because it was not updated, automated backups began failing without immediate detection. As a result, the database transaction log continued to grow until it reached its configured size limit. Once this limit was reached, the database was unable to process transactions, resulting in the service interruption. The missed certificate has since been updated, backup operations have been verified to be functioning normally, and the transaction log has been returned to standard operating levels. We are currently reviewing monitoring and validation procedures to ensure all certificates are properly accounted for during renewals and that backup failures are detected more promptly in the future.

Read the full incident report →

Started Oct 09, 2025, 08:15 PM UTC· resolved Oct 10, 2025, 02:50 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →