tag:status.telerivet.com,2005:/historyTelerivet Status - Incident History2024-03-28T15:47:21ZTelerivettag:status.telerivet.com,2005:Incident/161303452023-02-14T23:12:36Z2023-02-14T23:12:36ZEmails not being sent<p><small>Feb <var data-var='date'>14</var>, <var data-var='time'>23:12</var> UTC</small><br><strong>Resolved</strong> - Outgoing emails were delayed between 01:08 and 01:55 UTC due to a DNS change made by Telerivet's transactional email service provider (SendGrid), which was incompatible with a configuration setting on Telerivet's servers. This issue has been resolved by updating a configuration setting on Telerivet's servers.</p><p><small>Feb <var data-var='date'>14</var>, <var data-var='time'>02:06</var> UTC</small><br><strong>Monitoring</strong> - Telerivet has implemented a workaround and emails are being sent now.</p><p><small>Feb <var data-var='date'>14</var>, <var data-var='time'>01:35</var> UTC</small><br><strong>Identified</strong> - Telerivet's servers are currently unable to send email due to an issue with our transactional email service provider.</p>tag:status.telerivet.com,2005:Incident/86795302021-11-25T04:20:34Z2021-11-25T04:20:34ZDelays in updating search indexes<p><small>Nov <var data-var='date'>25</var>, <var data-var='time'>04:20</var> UTC</small><br><strong>Resolved</strong> - Telerivet has deployed a fix to improve performance of indexing new messages for search. New messages are currently being indexed without a delay.</p><p><small>Nov <var data-var='date'>24</var>, <var data-var='time'>12:41</var> UTC</small><br><strong>Update</strong> - Telerivet has implented an update to prioritize indexing of contacts. New and updated contacts are now appearing in search without a significant delay.</p><p><small>Nov <var data-var='date'>24</var>, <var data-var='time'>12:05</var> UTC</small><br><strong>Identified</strong> - Telerivet is currently experiencing delays updating search indexes for contacts and messages. After adding or updating contacts, the updated contacts may not appear in the Telerivet web app immediately. Searching for messages may not return new results.</p>tag:status.telerivet.com,2005:Incident/70623422021-05-23T03:47:03Z2021-05-23T03:47:03ZDatabase connectivity issue<p><small>May <var data-var='date'>23</var>, <var data-var='time'>03:47</var> UTC</small><br><strong>Resolved</strong> - Telerivet has not detected any further issues with database connectivity or data integrity, and has verified that no scheduled messages or other data were lost due to this issue.</p><p><small>May <var data-var='date'>22</var>, <var data-var='time'>14:39</var> UTC</small><br><strong>Monitoring</strong> - The issue was caused by a corrupted database table storing scheduled messages and other scheduled events, which caused the database server to crash when triggering scheduled events. The corrupted database table has been repaired, and scheduled messages are being sent now. All Telerivet functionality should be working normally.</p><p><small>May <var data-var='date'>22</var>, <var data-var='time'>14:32</var> UTC</small><br><strong>Update</strong> - We are continuing to work on a fix for this issue.</p><p><small>May <var data-var='date'>22</var>, <var data-var='time'>13:56</var> UTC</small><br><strong>Identified</strong> - The issue has been identified as a particular query causing Telerivet's database server to crash. Telerivet has disabled scheduled message functionality to avoid this issue and is continuing to investigate the issue.</p><p><small>May <var data-var='date'>22</var>, <var data-var='time'>13:41</var> UTC</small><br><strong>Update</strong> - We are continuing to investigate this issue.</p><p><small>May <var data-var='date'>22</var>, <var data-var='time'>13:41</var> UTC</small><br><strong>Investigating</strong> - Telerivet is currently investigating an issue with database connectivity.</p>tag:status.telerivet.com,2005:Incident/60056522021-01-13T18:45:13Z2021-01-13T18:45:13ZDatabase connectivity issue<p><small>Jan <var data-var='date'>13</var>, <var data-var='time'>18:45</var> UTC</small><br><strong>Resolved</strong> - Telerivet has not encountered any issues with database connectivity since reverting the software update yesterday. All systems are operating normally.</p><p><small>Jan <var data-var='date'>12</var>, <var data-var='time'>16:23</var> UTC</small><br><strong>Monitoring</strong> - The issue with intermittent database connectivity appears to have been triggered by a software update. Telerivet has reverted this update and is continuing to investigate the issue.</p><p><small>Jan <var data-var='date'>12</var>, <var data-var='time'>15:01</var> UTC</small><br><strong>Investigating</strong> - Telerivet is currently experiencing intermittent issues with database connectivity which could impact message delivery and service processing. We are currently investigating this issue.</p>tag:status.telerivet.com,2005:Incident/46445152020-07-18T00:21:40Z2020-07-18T00:21:40ZNexmo API outage<p><small>Jul <var data-var='date'>18</var>, <var data-var='time'>00:21</var> UTC</small><br><strong>Resolved</strong> - Nexmo has reported that all services have recovered. For more information, see https://www.nexmostatus.com/incidents/6p4nlld7n4br .</p><p><small>Jul <var data-var='date'>17</var>, <var data-var='time'>21:37</var> UTC</small><br><strong>Identified</strong> - Messages sent via Nexmo routes are currently encountering errors due to an ongoing issue with the Nexmo (Vonage) service. For more information, see https://www.nexmostatus.com/incidents/6p4nlld7n4br . Non-Nexmo routes are operating normally.</p>tag:status.telerivet.com,2005:Incident/43249552020-06-10T01:21:50Z2020-06-10T01:21:50ZNexmo API outage<p><small>Jun <var data-var='date'>10</var>, <var data-var='time'>01:21</var> UTC</small><br><strong>Resolved</strong> - Nexmo has reported that all services have recovered. For more information, see https://www.nexmostatus.com/incidents/ykf63np3bq89 .</p><p><small>Jun <var data-var='date'> 9</var>, <var data-var='time'>23:09</var> UTC</small><br><strong>Identified</strong> - Messages sent via Nexmo routes are currently encountering errors due to an ongoing issue with the Nexmo service. For more information, see https://www.nexmostatus.com/incidents/ykf63np3bq89 . Non-Nexmo routes are operating normally.</p>tag:status.telerivet.com,2005:Incident/31154162019-11-01T22:06:40Z2019-11-01T22:06:40ZNexmo messages not delivered<p><small>Nov <var data-var='date'> 1</var>, <var data-var='time'>22:06</var> UTC</small><br><strong>Resolved</strong> - On October 17, one of Nexmo's US partners identified un-permitted content in outgoing SMS and advised Nexmo to stop that traffic immediately. As a result, Nexmo temporarily blocked all messages sent from that route, which included all messages sent by users with virtual numbers in the US and Canada under Telerivet's Nexmo account. Nexmo has not indicated whether any Telerivet user was responsible for sending un-permitted content. <br /><br />Nexmo has reported that they are planning to improve their internal processes to avoid a situation like this from happening again.<br /><br />Telerivet has already been updated to require manual approval of each user who requests to send messages via Telerivet's Nexmo account, to reduce the risk of Telerivet users sending un-permitted content. <br /><br />Telerivet has already credited affected users with the cost of messages that were not delivered due to this issue, as well as 25% of their monthly service plan fee.</p><p><small>Oct <var data-var='date'>17</var>, <var data-var='time'>22:47</var> UTC</small><br><strong>Monitoring</strong> - SMS messages sent via Nexmo are being delivered again now. The issue was limited to clients using Telerivet's Nexmo account to send SMS messages in the United States and Canada. Clients using their own Nexmo account were unaffected. Nexmo disabled Telerivet's SMS routes in the US and Canada at 7:25 AM PDT, without notifying Telerivet. Nexmo restored these routes at 2:43 PM PDT. Telerivet is continuing to communicate with Nexmo to determine the reason why Nexmo disabled Telerivet's SMS routes in the US and Canada, and to prevent this issue from reoccurring.</p><p><small>Oct <var data-var='date'>17</var>, <var data-var='time'>16:57</var> UTC</small><br><strong>Identified</strong> - Users with routes provided by Nexmo have been reporting that messages are currently not being delivered with the error "Unroutable". Telerivet is currently working with Nexmo to resolve this issue.</p>tag:status.telerivet.com,2005:Incident/22588342019-03-14T00:03:10Z2019-03-14T00:03:10ZDelays in Nexmo message delivery<p><small>Mar <var data-var='date'>14</var>, <var data-var='time'>00:03</var> UTC</small><br><strong>Resolved</strong> - This issue has been resolved by Nexmo, and messages that queued during the incident have been delivered. For more information, see https://www.nexmostatus.com/incidents/jzgfpqrh4dqs .</p><p><small>Mar <var data-var='date'>13</var>, <var data-var='time'>20:33</var> UTC</small><br><strong>Identified</strong> - SMS messages sent via Nexmo in the US and Canada may not be received at this time due to an issue with Nexmo. For more information, see https://www.nexmostatus.com/incidents/jzgfpqrh4dqs .</p>tag:status.telerivet.com,2005:Incident/19020962018-09-11T19:50:59Z2018-09-11T19:51:19ZNexmo outage<p><small>Sep <var data-var='date'>11</var>, <var data-var='time'>19:50</var> UTC</small><br><strong>Resolved</strong> - The Nexmo API outage was resolved about 5 hours ago. For more information, see https://www.nexmostatus.com/incidents/qdl3bhsq1cbz</p><p><small>Sep <var data-var='date'>11</var>, <var data-var='time'>14:26</var> UTC</small><br><strong>Identified</strong> - Users sending SMS via Nexmo have been receiving a "HTTP 504" (Gateway Timeout) error due to an outage with Nexmo. For more information, see https://www.nexmostatus.com/ .</p>tag:status.telerivet.com,2005:Incident/14446492017-10-26T04:08:15Z2017-10-26T04:08:15ZInternal network connectivity issue<p><small>Oct <var data-var='date'>26</var>, <var data-var='time'>04:08</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Oct <var data-var='date'>26</var>, <var data-var='time'>00:42</var> UTC</small><br><strong>Monitoring</strong> - One of Telerivet's API servers experienced errors connecting to other Telerivet services at 00:22 UTC, for about 1 minute, causing some API requests to fail. Telerivet's services are currently operational. We are continuing to monitor for additional issues.</p>tag:status.telerivet.com,2005:Incident/13673072017-09-20T00:40:30Z2017-09-20T00:40:30ZMessage queue issue<p><small>Sep <var data-var='date'>20</var>, <var data-var='time'>00:40</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Sep <var data-var='date'>19</var>, <var data-var='time'>21:08</var> UTC</small><br><strong>Monitoring</strong> - At 19:40 UTC, one of Telerivet's message queue servers failed, causing errors when sending messages via the Telerivet web app and REST API. Telerivet's automated failover systems resolved the issue within 45 seconds, and all systems are currently operational.</p>tag:status.telerivet.com,2005:Incident/13423302017-08-30T06:33:14Z2017-08-30T06:33:14ZNetworking issues<p><small>Aug <var data-var='date'>30</var>, <var data-var='time'>06:33</var> UTC</small><br><strong>Resolved</strong> - The networking problem with the REST API load balancer has been resolved by Google Compute Engine. No further networking issues have been observed or reported for the past 3 hours.</p><p><small>Aug <var data-var='date'>30</var>, <var data-var='time'>02:49</var> UTC</small><br><strong>Identified</strong> - A load balancer serving the Telerivet REST API stopped routing external traffic to Telerivet's servers at 02:29 UTC, causing all REST API requests to fail. Telerivet updated the DNS entries at 02:37 UTC to bypass this load balancer, and the REST API should now be working again. Telerivet is continuing to monitor networking issues within our primary datacenter.</p>tag:status.telerivet.com,2005:Incident/11423662017-02-28T22:18:54Z2017-02-28T22:18:54ZAmazon S3 Outage<p><small>Feb <var data-var='date'>28</var>, <var data-var='time'>22:18</var> UTC</small><br><strong>Resolved</strong> - The Amazon S3 outage has ended, so MMS and recorded audio are now working in Telerivet. We are planning to integrate with an additional storage provider to mitigate the impact of future S3 outages on Telerivet's service.</p><p><small>Feb <var data-var='date'>28</var>, <var data-var='time'>19:10</var> UTC</small><br><strong>Monitoring</strong> - Due to an outage in Amazon S3, Telerivet is currently unable to receive or display MMS (multimedia messages) or play voice calls with recorded audio. Telerivet's SMS functionality is not affected by the S3 outage, and voice calls can play text-to-speech or an audio file from a URL outside of Amazon S3.</p>tag:status.telerivet.com,2005:Incident/11162712017-02-08T20:57:43Z2017-02-08T20:57:43ZIntermittent errors with message queue<p><small>Feb <var data-var='date'> 8</var>, <var data-var='time'>20:57</var> UTC</small><br><strong>Resolved</strong> - It seems likely that the intermittent errors were caused by a new setting we were testing for certain message queues, including some queues that were processing a high number of messages when the errors occurred. We have disabled this setting for these queues and will continue monitoring to see if the errors recur.</p><p><small>Feb <var data-var='date'> 8</var>, <var data-var='time'>09:45</var> UTC</small><br><strong>Monitoring</strong> - The errors with the message queue appear to have been resolved, however we are still investigating the root cause.</p><p><small>Feb <var data-var='date'> 8</var>, <var data-var='time'>09:17</var> UTC</small><br><strong>Investigating</strong> - We are currently investigating intermittent errors with the message queue.</p>tag:status.telerivet.com,2005:Incident/9623622016-10-29T00:23:13Z2016-10-29T00:23:13ZIssue with message queue<p><small>Oct <var data-var='date'>29</var>, <var data-var='time'>00:23</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Oct <var data-var='date'>25</var>, <var data-var='time'>09:37</var> UTC</small><br><strong>Monitoring</strong> - One of Telerivet's message queue servers experienced slow response times and elevated error rates from approximately 2:12 AM PDT until we restarted it at 2:28 AM PDT. We will continue to monitor the message queue and investigate the root cause of the incident.</p>tag:status.telerivet.com,2005:Incident/9567132016-10-25T09:40:33Z2016-10-25T09:40:33ZErrors sending messages to Nexmo<p><small>Oct <var data-var='date'>25</var>, <var data-var='time'>09:40</var> UTC</small><br><strong>Resolved</strong> - The outage of Nexmo on Friday was related to the large distributed denial of service attack against Dyn (https://en.wikipedia.org/wiki/October_2016_Dyn_cyberattack). No additional DNS outages have been observed since Friday.</p><p><small>Oct <var data-var='date'>21</var>, <var data-var='time'>17:36</var> UTC</small><br><strong>Monitoring</strong> - We have temporarily hardcoded the IP addresses of Nexmo's servers on Telerivet's servers, so Nexmo should be working again.</p><p><small>Oct <var data-var='date'>21</var>, <var data-var='time'>17:26</var> UTC</small><br><strong>Identified</strong> - Due to a DNS outage in Nexmo's infrastructure, Telerivet is currently encountering errors when sending messages to Nexmo. We are working to resolve this issue.</p>tag:status.telerivet.com,2005:Incident/5002742016-05-11T05:32:24Z2016-05-11T05:32:24ZIssue with message queue<p><small>May <var data-var='date'>11</var>, <var data-var='time'>05:32</var> UTC</small><br><strong>Resolved</strong> - At approximately 00:10 UTC, one of our servers running RabbitMQ (the software that Telerivet uses internally to queue messages and other tasks) began experiencing very high CPU usage, very slow response times, and intermittent errors when queueing or dequeueing messages.
<br />
<br />During this time, messages were still able to be queued (with intermittent errors), and only 2% of API requests failed; however, the slow response times and intermittent errors from RabbitMQ caused the worker processes dequeuing messages to gradually fall further and further behind.
<br />
<br />Switching to a standby server in our RabbitMQ cluster did not resolve the issue. Eventually, we restarted the RabbitMQ process, at which time the CPU usage returned to normal, the intermittent errors stopped, and the worker processes quickly caught up.
<br />
<br />At this time, Telerivet has not yet identified a particular bug or configuration issue with RabbitMQ that caused this issue. In the next few days, we will be upgrading RabbitMQ to the latest release, as well as performing additional testing to try to reproduce the behavior in RabbitMQ outside of Telerivet's production environment.</p><p><small>May <var data-var='date'>11</var>, <var data-var='time'>01:15</var> UTC</small><br><strong>Monitoring</strong> - The message queue returned to normal at approximately 00:59, and messages queued during the delay have been sent. We are continuing to investigate the root cause of the delays and intermittent errors with the message queue to prevent the issue from happening again.</p><p><small>May <var data-var='date'>11</var>, <var data-var='time'>00:36</var> UTC</small><br><strong>Investigating</strong> - Telerivet is currently observing long response times and intermittent errors with the message queue, and we are currently working to resolve the issue.</p>tag:status.telerivet.com,2005:Incident/4641112016-04-13T05:10:00Z2016-04-13T05:10:00ZDatacenter connectivity issue<p><small>Apr <var data-var='date'>13</var>, <var data-var='time'>05:10</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Apr <var data-var='date'>12</var>, <var data-var='time'>18:32</var> UTC</small><br><strong>Monitoring</strong> - At 02:09 UTC, Google Compute Engine began experiencing severe network connectivity issues worldwide ( https://status.cloud.google.com/incident/compute/16007 ). In preparation for this type of outage, Telerivet has a standby datacenter from another hosting provider (Amazon Web Services), which we activated at 02:19 UTC. Most Telerivet services were operational at that time, except for search and some SMPP shortcode connections. SMPP connections were reactivated over the next half hour. Google resolved the issue with Google Compute Engine at 02:27 UTC, and subsequently we reactivated our primary datacenter in Google Compute Engine.
<br />
<br />Search indexes for each project have gradually been coming back online. Search is now available for most active projects, and should become available in all projects over the next several hours.</p><p><small>Apr <var data-var='date'>12</var>, <var data-var='time'>02:25</var> UTC</small><br><strong>Identified</strong> - Telerivet's primary datacenter in Google Compute Engine is currently experiencing network connectivity issues, so we have activated Telerivet's secondary datacenter in Amazon Web Services. Most services should now be functional, although search may be unavailable.</p>tag:status.telerivet.com,2005:Incident/3976362016-01-16T22:57:35Z2016-01-16T22:57:35ZScheduled datacenter migration<p><small>Jan <var data-var='date'>16</var>, <var data-var='time'>22:57</var> UTC</small><br><strong>Completed</strong> - The migration to Google Compute Engine is complete.</p><p><small>Jan <var data-var='date'>16</var>, <var data-var='time'>20:00</var> UTC</small><br><strong>In progress</strong> - Scheduled maintenance is currently in progress. We will provide updates as necessary.</p><p><small>Jan <var data-var='date'>15</var>, <var data-var='time'>22:56</var> UTC</small><br><strong>Scheduled</strong> - Telerivet will be moving its primary data center from AWS to Google Compute Engine tomorrow (Saturday, January 16) between 12:00pm - 2:00pm PST (20:00 - 22:00 UTC). No downtime is expected, although some errors or performance issues may occur. Search and dynamic groups will be unavailable while the index is rebuilt. However, recently active projects will be reindexed first, so most active projects will only experience a few minutes where search is unavailable.</p>tag:status.telerivet.com,2005:Incident/3893642016-01-02T22:56:22Z2016-01-02T22:56:22ZScheduled datacenter migration<p><small>Jan <var data-var='date'> 2</var>, <var data-var='time'>22:56</var> UTC</small><br><strong>Completed</strong> - The migration to AWS is complete, and all Telerivet services are currently operational.</p><p><small>Jan <var data-var='date'> 2</var>, <var data-var='time'>22:01</var> UTC</small><br><strong>In progress</strong> - Telerivet's servers migrated to an AWS data center 1 hour ago and appear to be operating smoothly. The search index is currently being rebuilt, and is anticipated to be ready about 1 hour from now.</p><p><small>Jan <var data-var='date'> 2</var>, <var data-var='time'>17:17</var> UTC</small><br><strong>Scheduled</strong> - In order to avoid the continuing DDoS attacks against Linode, Telerivet will be moving to a secondary data center (AWS) in approximately 3 hours. No downtime is expected, although some errors or performance issues may occur. Search and dynamic groups will be unavailable for approximately 1 hour while the index is rebuilt. SMPP connections will continue to be routed via Linode's data center in order to maintain connectivity for users with connections fixed to a Linode IP address.</p>tag:status.telerivet.com,2005:Incident/3886362016-01-02T17:02:31Z2016-01-02T17:02:31ZDatacenter connectivity issue<p><small>Jan <var data-var='date'> 2</var>, <var data-var='time'>17:02</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Jan <var data-var='date'> 1</var>, <var data-var='time'>16:23</var> UTC</small><br><strong>Update</strong> - Search and dynamic groups are now available, and all Telerivet services are operational.</p><p><small>Jan <var data-var='date'> 1</var>, <var data-var='time'>14:32</var> UTC</small><br><strong>Update</strong> - Due to DDoS attacks in the secondary data center, Telerivet has returned to the primary data center, and most services are operational. Search and dynamic groups are temporarily unavailable while we rebuild the index. All SMPP connections should be working now.</p><p><small>Dec <var data-var='date'>31</var>, <var data-var='time'>23:02</var> UTC</small><br><strong>Update</strong> - Linode has published an update about the DDoS attacks at http://status.linode.com/incidents/mmdbljlglnfd</p><p><small>Dec <var data-var='date'>31</var>, <var data-var='time'>16:35</var> UTC</small><br><strong>Monitoring</strong> - All services are currently operational in Telerivet's secondary data center. Search, dynamic groups, Android real-time connections, and SMPP connections are now working, with the exception of a small number of SMPP connections where the mobile network or aggregator requires a particular IP address in our primary data center. As the primary data center remains under DDoS attack at this time, Telerivet will remain in the secondary data center for now.</p><p><small>Dec <var data-var='date'>31</var>, <var data-var='time'>12:44</var> UTC</small><br><strong>Identified</strong> - Telerivet's primary data center is again experiencing DDoS attacks ( http://status.linode.com/incidents/5ryq5w4l2mfj ), so we have relocated Telerivet to another data center. Some functionality (full-text search, dynamic groups, and SMPP connections) is currently unavailable in the new data center, and we are working to restore those services.</p>tag:status.telerivet.com,2005:Incident/3883802015-12-31T06:17:12Z2015-12-31T06:17:12ZDatacenter connectivity issue<p><small>Dec <var data-var='date'>31</var>, <var data-var='time'>06:17</var> UTC</small><br><strong>Resolved</strong> - This incident is marked as resolved, because no network interruptions have been observed in the past several hours. In the meantime, we're actively working on improving our systems to increase reliability and reduce downtime in case of further DDoS attacks targeted at Linode.</p><p><small>Dec <var data-var='date'>30</var>, <var data-var='time'>23:48</var> UTC</small><br><strong>Monitoring</strong> - Network connectivity at Telerivet's primary data center has apparently returned to normal, so we have returned Telerivet to that data center, and all services are currently operational.</p><p><small>Dec <var data-var='date'>30</var>, <var data-var='time'>22:39</var> UTC</small><br><strong>Investigating</strong> - Telerivet's primary data center is currently experiencing DDoS attacks ( http://status.linode.com/incidents/rknrs83pgjxv ), so we have relocated Telerivet to another data center. Some functionality (full-text search, dynamic groups, and SMPP connections) is currently unavailable in the new data center, and we are working to restore those services.</p>tag:status.telerivet.com,2005:Incident/3860942015-12-27T20:22:00Z2015-12-27T20:28:29ZDatacenter connectivity issue<p><small>Dec <var data-var='date'>27</var>, <var data-var='time'>20:22</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved. Additional standby servers have been provisioned in a separate datacenter to reduce downtime in case Telerivet's primary data center has another extended outage in the future.</p><p><small>Dec <var data-var='date'>27</var>, <var data-var='time'>09:17</var> UTC</small><br><strong>Monitoring</strong> - Linode appears to have mitigated the DDoS attack in the London data center, and Telerivet is currently online.</p><p><small>Dec <var data-var='date'>27</var>, <var data-var='time'>08:51</var> UTC</small><br><strong>Identified</strong> - Telerivet's datacenter is working to mitigate a large DDoS attack. See http://status.linode.com/incidents/ksvn7mxm8mz2 for updates.</p><p><small>Dec <var data-var='date'>27</var>, <var data-var='time'>05:17</var> UTC</small><br><strong>Investigating</strong> - Telerivet's data center is currently experiencing network connectivity issues, causing Telerivet services to be inaccessible. More updates will be provided as information becomes available.</p>tag:status.telerivet.com,2005:Incident/3200232015-09-21T21:23:06Z2015-09-21T21:23:06ZNetwork connectivity issue<p><small>Sep <var data-var='date'>21</var>, <var data-var='time'>21:23</var> UTC</small><br><strong>Resolved</strong> - Between 20:15 UTC and 20:18 UTC, and between 20:36 UTC and 20:49 UTC, there were periods of intermittent loss of network connectivity to Telerivet's servers due to network maintenance in Telerivet's data center. At this time the network issues have been resolved.</p><p><small>Sep <var data-var='date'>21</var>, <var data-var='time'>20:42</var> UTC</small><br><strong>Investigating</strong> - We're currently investigating network connectivity issues with several of our servers.</p>tag:status.telerivet.com,2005:Incident/3082342015-09-05T00:35:19Z2015-09-05T00:35:19ZNetwork connectivity issue<p><small>Sep <var data-var='date'> 5</var>, <var data-var='time'>00:35</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Sep <var data-var='date'> 4</var>, <var data-var='time'>22:23</var> UTC</small><br><strong>Monitoring</strong> - Telerivet's servers appear to be reachable again via all networks. It appears that an internet routing issue temporarily prevented certain networks from reaching Telerivet's data center.</p><p><small>Sep <var data-var='date'> 4</var>, <var data-var='time'>21:30</var> UTC</small><br><strong>Investigating</strong> - Some external networks are currently unable to connect to Telerivet's servers. We are currently investigating.</p>