Monnit incident

service outage

Minor Resolved View vendor source →

Monnit experienced a minor incident on October 11, 2026 affecting Web Portal and Gateway Service and 1 more component, lasting 1h 17m. The incident has been resolved; the full update timeline is below.

Started
Oct 11, 2026, 07:04 PM UTC
Resolved
Oct 11, 2026, 08:22 PM UTC
Duration
1h 17m
Detected by Pingoru
Oct 11, 2026, 07:04 PM UTC

Affected components

Web PortalGateway ServiceNotification DeliveryWebhook DeliveryRest API

Update timeline

  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.