Simwood Status - Incident Historyhttps://status.simwood.com
StatuspageFri, 22 Feb 2019 13:58:52 +0000Database Upgrades
<p><strong>THIS IS A SCHEDULED EVENT Feb <var data-var='date'>24</var>, <var data-var='time'>09:00</var> - <var data-var='time'>12:00</var> UTC</strong></p><p><small>Feb <var data-var='date'>22</var>, <var data-var='time'>12:37</var> UTC</small><br><strong>Scheduled</strong> - We are undertaking upgrades of our Redis database cluster on Sunday morning between 0900 and 1200. This time was selected to minimise the risk of disruption.<br /><br />Whilst we are confident this will not affect production traffic, it may impact the portal and API briefly, such as traffic statistics and some limits (e.g. concurrent calls) may not be enforced for a small period during the upgrade works.<br /><br />Throughout the planned works we will update this status page as appropriate and tickets will be monitored.</p> Sun, 24 Feb 2019 09:00:00 +0000https://status.simwood.com/incidents/cp5n7t18hzrr
https://status.simwood.com/incidents/cp5n7t18hzrrAT RISK - Slough SS7 Upgrades
<p><small>Feb <var data-var='date'>21</var>, <var data-var='time'>21:19</var> UTC</small><br><strong>Completed</strong> - The planned maintenance has been completed without incident, this site should no longer be considered at risk.</p><p><small>Feb <var data-var='date'>15</var>, <var data-var='time'>15:14</var> UTC</small><br><strong>Scheduled</strong> - As part of planned maintenance, we will be upgrading one of our SS7 switches in Slough on the 21st February from 2000 UTC. This time has been selected to minimise any potential disruption due to the brief reduction in capacity this will cause as the switch must be restarted to complete these works. <br /><br />This is an AT RISK notification only, as it temporarily reduces our headroom in the Slough site. Calls will be routed away from the affected switch in advance of the upgrade works and this will not affect the ability to place or receive calls.</p> Thu, 21 Feb 2019 21:19:48 +0000https://status.simwood.com/incidents/mlhxxp1c8cqz
https://status.simwood.com/incidents/mlhxxp1c8cqzAT RISK - Manchester
<p><small>Feb <var data-var='date'>20</var>, <var data-var='time'>10:58</var> UTC</small><br><strong>Resolved</strong> - An issue with the switchgear controller was identified and this has been reset with assistance from the vendor. This has resolved the issue as of 10:40UTC.</p><p><small>Feb <var data-var='date'>20</var>, <var data-var='time'>09:58</var> UTC</small><br><strong>Monitoring</strong> - At 8:31 this morning, a power event caused a failover to generator power in our Manchester facility. <br /><br />There was no impact but this site is currently at risk until mains power is restored. <br /><br />No impact is expected when the power is restored. No expected restoration time for mains power is available at present.</p> Wed, 20 Feb 2019 10:58:52 +0000https://status.simwood.com/incidents/0ck7rnp1f72n
https://status.simwood.com/incidents/0ck7rnp1f72nReduced fibre network redundancy
<p><small>Feb <var data-var='date'>20</var>, <var data-var='time'>08:50</var> UTC</small><br><strong>Resolved</strong> - This link has remained stable overnight, restoring full N+2 redundancy.<br /><br />The cause of this was a bend at a fibre splice point between Sovereign House and Volta following works in vicinity.</p><p><small>Feb <var data-var='date'>19</var>, <var data-var='time'>21:06</var> UTC</small><br><strong>Monitoring</strong> - This fibre span was brought back into service at 21:00UTC.<br /><br />We are monitoring to confirm the underlying issue is resolved.</p><p><small>Feb <var data-var='date'>19</var>, <var data-var='time'>08:32</var> UTC</small><br><strong>Identified</strong> - We have seen multiple flaps on one of our physical fibre spans around London overnight, suggesting physical disturbance. We have preemptively shut down links using this whilst it is investigated and corrected. This reduced redundancy around our London ring but as we have multiple other paths, no service impact is expected.</p> Wed, 20 Feb 2019 08:50:49 +0000https://status.simwood.com/incidents/gxc42hdd54vp
https://status.simwood.com/incidents/gxc42hdd54vpAT RISK - London SS7 Upgrades
<p><small>Feb <var data-var='date'>19</var>, <var data-var='time'>21:57</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed without issue.<br /><br />This service should no longer be considered AT RISK</p><p><small>Feb <var data-var='date'>15</var>, <var data-var='time'>15:13</var> UTC</small><br><strong>Scheduled</strong> - As part of planned maintenance, we will be upgrading one of our SS7 switches in London on the 19th February from 2000 UTC. This time has been selected to minimise any potential disruption due to the brief reduction in capacity this will cause as the switch must be restarted to complete these works. <br /><br />This is an AT RISK notification only, as it temporarily reduces our headroom in the London site. Calls will be routed away from the affected switch in advance of the upgrade works and this will not affect the ability to place or receive calls.</p> Tue, 19 Feb 2019 21:57:07 +0000https://status.simwood.com/incidents/lz089kbwlfzy
https://status.simwood.com/incidents/lz089kbwlfzyContainerisation update - London Volta
<p><small>Feb <var data-var='date'>17</var>, <var data-var='time'>18:00</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Feb <var data-var='date'>16</var>, <var data-var='time'>10: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'>13</var>, <var data-var='time'>10:21</var> UTC</small><br><strong>Scheduled</strong> - We will be rebuilding our container hosts in Volta to reflect a decision to change host operating system.<br /><br />DNS will be updated to direct traffic to other sites for customers configured in accordance with our interop. Site specific IP addresses will failover between nodes yet our interop specifies that customers should not send directly to an IP address and, if doing so is unavoidable, customers should configure their own fail-over to other sites. Anycast services will be served from the next closest node but routing will change.<br /><br />This maintenance should therefore not be service affecting but the network is considered at risk through a reduced level of redundancy during it.</p> Sun, 17 Feb 2019 18:00:16 +0000https://status.simwood.com/incidents/041z3vmzqscy
https://status.simwood.com/incidents/041z3vmzqscyChannel Information
<p><small>Feb <var data-var='date'>14</var>, <var data-var='time'>17:56</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Feb <var data-var='date'>14</var>, <var data-var='time'>14:42</var> UTC</small><br><strong>Investigating</strong> - We are currently investigating an issue that is causing inaccurate information to be displayed in the utilisation graphs in the portal and reflected in information returned via the API.<br /><br />This relates only to display of information, calls are unaffected.</p> Thu, 14 Feb 2019 17:56:31 +0000https://status.simwood.com/incidents/vpph57m9ksc7
https://status.simwood.com/incidents/vpph57m9ksc7Outbound calls via Slough using SIP AUTH failing
<p><small>Feb <var data-var='date'>12</var>, <var data-var='time'>12:21</var> UTC</small><br><strong>Resolved</strong> - Some outbound calls via Slough that used SIP AUTH were failing due to requests being directed to a database node that was not responding correctly, but did not failover.<br /><br />Inbound calls were unaffected, as were all calls using IP authentication. Outbound calls using SIP AUTH trunks to all other sites were also unaffected. The problem was cleared by 11:20am<br /><br />Customers who have configured their services to automatically fail over to our other sites according to our interop guide at https://support.simwood.com/hc/en-us/articles/115008835528-Outbound-SIP should not have been affected.<br /><br />This status update is retrospective. We would normally issue status page updates during an incident such as this and apologise for that omission.</p> Tue, 12 Feb 2019 12:21:21 +0000https://status.simwood.com/incidents/2rdfvr9486c3
https://status.simwood.com/incidents/2rdfvr9486c3Increased PDD
<p><small>Feb <var data-var='date'> 5</var>, <var data-var='time'>16:36</var> UTC</small><br><strong>Resolved</strong> - This site has been stable for several hours, and has now been returned to full normal service.<br /><br />The cause of this issue was two severely loaded voice processing nodes which, whilst responding to health checks normally, were slower than normal responding to call set-ups. This caused increased PDD for calls hitting them, and greatly increased PDD in less frequent cases where subsequent failover was from one loaded node to the other. Once these were removed from service, new calls were successfully distributed across remaining nodes which were performing normally. The true root cause of the excess load is unknown, but given calls are load balanced across all nodes, and this was not capacity related, we suspect a bug in the underlying code.<br /><br />This only affected some calls to our London node and DNS was rapidly failed over to other sites. However, we continued to see large flows of traffic to the London site regardless of the change, suggesting it was being forced to the specific IP address or customer equipment was not reflecting the DNS change. Customers are again reminded of our interop guidance which ensures an issue in a single site should not affect call completion.</p><p><small>Feb <var data-var='date'> 5</var>, <var data-var='time'>10:40</var> UTC</small><br><strong>Monitoring</strong> - Normal service in the London site was restored at 1005. <br /><br />We are monitoring the situation and will restore normal DNS after testing is completed.</p><p><small>Feb <var data-var='date'> 5</var>, <var data-var='time'>09:57</var> UTC</small><br><strong>Update</strong> - As this is limited to the London site, we have amended DNS to route outbound SIP traffic to alternative sites whilst investigation continues.</p><p><small>Feb <var data-var='date'> 5</var>, <var data-var='time'>09:47</var> UTC</small><br><strong>Identified</strong> - We are investigating reports of increased PDD, in some cases resulting in call timeouts, on outbound calls over our London site. We will update this status page as soon as further information becomes available.</p> Tue, 05 Feb 2019 16:36:21 +0000https://status.simwood.com/incidents/cc29rtlskj87
https://status.simwood.com/incidents/cc29rtlskj87Intermittent Calls Failing
<p><small>Jan <var data-var='date'>30</var>, <var data-var='time'>22:26</var> UTC</small><br><strong>Resolved</strong> - We are confident this issue is resolved and will post an RFO shortly.</p><p><small>Jan <var data-var='date'>30</var>, <var data-var='time'>20:21</var> UTC</small><br><strong>Monitoring</strong> - We are continuing to monitor and will provide an RFO in the morning</p><p><small>Jan <var data-var='date'>30</var>, <var data-var='time'>19:51</var> UTC</small><br><strong>Update</strong> - Traffic is flowing again in the US as of 19:15, we are continuing to investigate</p><p><small>Jan <var data-var='date'>30</var>, <var data-var='time'>19:22</var> UTC</small><br><strong>Update</strong> - We have deployed a fix which has resolved the issue in the UK as of 18:40 and are working to deploy in our US sites</p><p><small>Jan <var data-var='date'>30</var>, <var data-var='time'>18:38</var> UTC</small><br><strong>Investigating</strong> - We are investigating sporadic reports of calls failing, we are investigating this and more information will be provided as soon as it becomes available.</p> Wed, 30 Jan 2019 22:26:57 +0000https://status.simwood.com/incidents/yzp5lg3m2l4h
https://status.simwood.com/incidents/yzp5lg3m2l4hContainerisation update - Slough
<p><small>Jan <var data-var='date'>27</var>, <var data-var='time'>18:00</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Jan <var data-var='date'>26</var>, <var data-var='time'>10: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'>13</var>, <var data-var='time'>10:19</var> UTC</small><br><strong>Scheduled</strong> - We will be rebuilding our container hosts in Slough to reflect a decision to change host operating system.<br /><br />This will also involve failing our master database node over once maintenance is complete.<br /><br />DNS will be updated to direct traffic to other sites for customers configured in accordance with our interop. Site specific IP addresses will failover between nodes yet our interop specifies that customers should not send directly to an IP address and, if doing so is unavoidable, customers should configure their own fail-over to other sites. Anycast services will be served from the next closest node but routing will change.<br /><br />This maintenance should therefore not be service affecting but the network is considered at risk through a reduced level of redundancy during it.</p> Sun, 27 Jan 2019 18:00:52 +0000https://status.simwood.com/incidents/vp0lybfv4h4k
https://status.simwood.com/incidents/vp0lybfv4h4kContainerisation update - Manchester
<p><small>Jan <var data-var='date'>20</var>, <var data-var='time'>19:00</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Jan <var data-var='date'>19</var>, <var data-var='time'>10: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'>13</var>, <var data-var='time'>10:14</var> UTC</small><br><strong>Update</strong> - We will be undergoing scheduled maintenance during this time.</p><p><small>Jan <var data-var='date'>13</var>, <var data-var='time'>10:14</var> UTC</small><br><strong>Scheduled</strong> - We will be rebuilding our container hosts in Manchester to reflect a decision to change host operating system.<br /><br />Manchester is technically deprecated and we advised changes running up to scaling it back in February, last August - http://blog.simwood.com/2018/08/network-changes/ . Therefore, Manchester specific SIP host names already point to other sites and whilst direct IP addresses still work, our interop specifies that customers should not send directly to an IP address and, if doing so is unavoidable, customers should configure their own fail-over to other sites. Therefore, whilst these addresses will go offline during this maintenance but it should not be service affecting for anyone configured properly.</p> Sun, 20 Jan 2019 19:00:25 +0000https://status.simwood.com/incidents/2ksjxgq6xz8x
https://status.simwood.com/incidents/2ksjxgq6xz8xNumbers Exported from Simwood
<p><small>Jan <var data-var='date'>11</var>, <var data-var='time'>11:44</var> UTC</small><br><strong>Resolved</strong> - This issue has been confirmed resolved and calls to all exported numbers are completing successfully.</p><p><small>Jan <var data-var='date'>11</var>, <var data-var='time'>10:41</var> UTC</small><br><strong>Monitoring</strong> - We believe this issue has been resolved, and have had confirmation of the same from one of the affected gaining providers.<br /><br />We’ll continue to monitor this closely and ask other CPs if you experience issues with calls to Simwood numbers ported to your network to use the details provided in the GNP Contact Register to report this to us.<br /><br />Please accept our apologies for any inconvenience caused.</p><p><small>Jan <var data-var='date'>11</var>, <var data-var='time'>10:23</var> UTC</small><br><strong>Investigating</strong> - We are investigating an issue where calls are failing to some numbers exported from Simwood, i.e. where Simwood is the LCP and the number has been ported to a new provider. <br /><br />This is only affecting numbers exported to some other operators and we’re investigating as a priority. <br /><br />No existing Simwood customer, or any number active on the Simwood network, is affected. <br /><br />Please accept our apologies for any inconvenience this may cause.</p> Fri, 11 Jan 2019 11:44:27 +0000https://status.simwood.com/incidents/pyl5lr4dxktc
https://status.simwood.com/incidents/pyl5lr4dxktcAT RISK - Emergency Database Maintenance
<p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>23:27</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>21:01</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'>10</var>, <var data-var='time'>17:54</var> UTC</small><br><strong>Scheduled</strong> - Please accept our apologies for the short notice but we will be undertaking essential database maintenance this evening from 2100 UTC. No interruption to service is anticipated, but there is a possibility that some API or portal functionality will be reduced for a short time including the ability to provision, or configure, numbering and trunks.<br /><br />Updates will be made via this page throughout, and when the works are complete. <br /><br />Please accept our apologies for any inconvenience this may cause.</p> Thu, 10 Jan 2019 23:27:58 +0000https://status.simwood.com/incidents/z1ryznfr0hpj
https://status.simwood.com/incidents/z1ryznfr0hpjAT RISK - London SS7
<p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>23:01</var> UTC</small><br><strong>Completed</strong> - This work has been completed without incident.</p><p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>19:53</var> UTC</small><br><strong>Update</strong> - Please note, this maintenance is in the London site, following the successful completion of similar in Slough last night. We apologise that the earlier announcement incorrectly indicated these works were being carried out in Slough on both evenings.<br /><br />Again, we do not anticipate any impact on services.</p><p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>19:01</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'> 7</var>, <var data-var='time'>10:51</var> UTC</small><br><strong>Scheduled</strong> - We will be undertaking planned maintenance as part of the works to upgrade our BT SS7 interconnects in Slough on the evenings of Wednesday 9th January and Thursday 10th January between 1900 and 0200 each day.<br /><br />This has been scheduled for when the network is quiet so this will not be service affecting, but this work will result in brief periods of reduced capacity and reduced resilience therefore the service should be considered AT RISK during this time.</p> Thu, 10 Jan 2019 23:01:43 +0000https://status.simwood.com/incidents/8190jbs497vm
https://status.simwood.com/incidents/8190jbs497vmAT RISK - Slough SS7
<p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>00:34</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Jan <var data-var='date'> 9</var>, <var data-var='time'>19: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'> 7</var>, <var data-var='time'>10:50</var> UTC</small><br><strong>Scheduled</strong> - We will be undertaking planned maintenance as part of the works to upgrade our BT SS7 interconnects in Slough on the evenings of Wednesday 9th January and Thursday 10th January between 1900 and 0200 each day.<br /><br />This has been scheduled for when the network is quiet so this will not be service affecting, but this work will result in brief periods of reduced capacity and reduced resilience therefore the service should be considered AT RISK during this time.</p> Thu, 10 Jan 2019 00:34:37 +0000https://status.simwood.com/incidents/k136v9vkpdj0
https://status.simwood.com/incidents/k136v9vkpdj0Inbound Calls to Ported Numbers
<p><small>Jan <var data-var='date'>10</var>, <var data-var='time'>00:15</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Jan <var data-var='date'> 9</var>, <var data-var='time'>22:25</var> UTC</small><br><strong>Monitoring</strong> - We believe this is now resolved and are monitoring the situation.</p><p><small>Jan <var data-var='date'> 9</var>, <var data-var='time'>21:51</var> UTC</small><br><strong>Investigating</strong> - We're aware of an intermittent issue affecting calls to some ported numbers. We're investigating this as a priority but it appears to affect a very limited number of calls, and only those originating from mobile networks or the London area.<br /><br />More information will be provided as soon as possible.</p> Thu, 10 Jan 2019 00:15:25 +0000https://status.simwood.com/incidents/b2qgqbc0q4wf
https://status.simwood.com/incidents/b2qgqbc0q4wfO2 Mobile Network Issues
<p><small>Dec <var data-var='date'> 7</var>, <var data-var='time'>00:28</var> UTC</small><br><strong>Resolved</strong> - O2 have announced that service is returning to normal and will be fully restored by around 0300.</p><p><small>Dec <var data-var='date'> 6</var>, <var data-var='time'>09:44</var> UTC</small><br><strong>Identified</strong> - We are aware of an outage affecting the O2 4G LTE network nationally. For more information see https://status.o2.co.uk/<br /><br />As a result, calls to some O2 numbers (and numbers ported to O2) may fail if the destination handset is on the 4G/LTE network. O2 is advising customers to disable 4G (using the 3G or 2G network which is working in most areas)<br /><br />Whilst this fault is entirely outwith our control, we anticipate you will see a high number of call failures to O2 destinations as a result.</p> Fri, 07 Dec 2018 00:28:07 +0000https://status.simwood.com/incidents/fqwh4pqhgl4y
https://status.simwood.com/incidents/fqwh4pqhgl4yDuplicate invoices
<p><small>Dec <var data-var='date'> 1</var>, <var data-var='time'>09:43</var> UTC</small><br><strong>Resolved</strong> - A small number of customers will have received duplicate invoices this morning with invoice numbers differing by one. Only the lower numbered invoice is valid and should be the only one visible in the portal; the second was sent but failed to commit as it was a duplicate. This was due to a legacy version of the code running in parallel and this has now been removed. Apologies for the inconvenience.</p> Sat, 01 Dec 2018 09:43:09 +0000https://status.simwood.com/incidents/yhspxbbzz2h9
https://status.simwood.com/incidents/yhspxbbzz2h9London Network - LINX LON1 Maintenance
<p><small>Nov <var data-var='date'>20</var>, <var data-var='time'>23:18</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Nov <var data-var='date'>20</var>, <var data-var='time'>23:10</var> UTC</small><br><strong>Verifying</strong> - Verification is currently underway for the maintenance items.</p><p><small>Nov <var data-var='date'>20</var>, <var data-var='time'>22:00</var> UTC</small><br><strong>In progress</strong> - Scheduled maintenance is currently in progress. We will provide updates as necessary.</p><p><small>Nov <var data-var='date'>20</var>, <var data-var='time'>14:25</var> UTC</small><br><strong>Scheduled</strong> - We are performing maintenance on our LINX LON1 port in London as part of our normal network reviews for resilience and quality.<br /><br />Whilst we anticipate no interruption to service during this work, and routing of customer traffic should not be affected, some paths will change which may manifest as short bursts of jitter while routes converge.</p> Tue, 20 Nov 2018 23:18:37 +0000https://status.simwood.com/incidents/h1slp31bt3mz
https://status.simwood.com/incidents/h1slp31bt3mzPorted Numbers (Magrathea)
<p><small>Nov <var data-var='date'> 9</var>, <var data-var='time'>11:47</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved by the LCP.</p><p><small>Nov <var data-var='date'> 9</var>, <var data-var='time'>11:14</var> UTC</small><br><strong>Identified</strong> - We’re aware of an issue affecting calls to numbers ported from Magrathea to Simwood. <br /><br />This is due to an issue within the LCP’s network and outwith our control. <br /><br />Apologies for any inconvenience this may cause.</p> Fri, 09 Nov 2018 11:47:46 +0000https://status.simwood.com/incidents/kmr3cf1tbvkl
https://status.simwood.com/incidents/kmr3cf1tbvklOutbound SMS Concatenation
<p><small>Nov <var data-var='date'> 6</var>, <var data-var='time'>18:16</var> UTC</small><br><strong>Resolved</strong> - We have identified an issue with our SMS billing which has resulted in some customers being undercharged for multi-part SMS messages, specifically where the concatenation limit was set to 1 (the default) we were transmitting longer messages rather than truncating them as outlined in the API documentation.<br /><br />This has now been corrected, and we do not intend to re-bill any messages sent historically, however please be aware that messages may be truncated as intended where they were not previously, in which case you will need to set the `concat` parameter to a higher value. Additionally, some customers may notice message content that was previously billed as one single part message are now (correctly) being billed as multi-part.</p> Tue, 06 Nov 2018 18:16:44 +0000https://status.simwood.com/incidents/fmfn921ck60g
https://status.simwood.com/incidents/fmfn921ck60gCLI and General Condition 6
<p><small>Nov <var data-var='date'> 6</var>, <var data-var='time'>18:11</var> UTC</small><br><strong>Completed</strong> - The scheduled maintenance has been completed.</p><p><small>Oct <var data-var='date'> 8</var>, <var data-var='time'>14:27</var> UTC</small><br><strong>Scheduled</strong> - With effect from Wednesday 10th October we will be implementing the first phase of CLI changes for compliance with the revised General Condition 6 as previously announced. <br /><br />It is imperative to ensure you are sending valid Caller ID on all calls as outbound calls that do not have any valid Caller ID will not complete after this date.<br /><br />To minimise impact of these changes we’ve implemented this in a manner that the vast majority of customers will be unaffected, and we will manipulate the CLI to meet the requirements behind the scenes even where only one CLI is present.<br /><br />For more information please see http://blog.simwood.com/2018/10/gc6-cli-update/</p> Tue, 06 Nov 2018 18:11:33 +0000https://status.simwood.com/incidents/df7rg661r47x
https://status.simwood.com/incidents/df7rg661r47xAPI Performance
<p><small>Oct <var data-var='date'>26</var>, <var data-var='time'>12:52</var> UTC</small><br><strong>Resolved</strong> - This earlier issue is now resolved, and the API should be performing as normal <br /><br />Please accept our apologies for any inconvenience caused.</p><p><small>Oct <var data-var='date'>26</var>, <var data-var='time'>12:32</var> UTC</small><br><strong>Investigating</strong> - We are aware of an issue adversely affecting the performance of some features of the API including CDRs and number listings, this is being investigated as a priority.<br /><br />This is quite isolated, and does not affect the voice platform, and number provisioning and configuration is working as normal.</p> Fri, 26 Oct 2018 12:52:05 +0000https://status.simwood.com/incidents/ymbg58s9ddhw
https://status.simwood.com/incidents/ymbg58s9ddhwUnusual CLI on Incoming Calls
<p><small>Oct <var data-var='date'>22</var>, <var data-var='time'>20:27</var> UTC</small><br><strong>Resolved</strong> - This incident has been resolved.</p><p><small>Oct <var data-var='date'>22</var>, <var data-var='time'>17:16</var> UTC</small><br><strong>Monitoring</strong> - We are aware of an issue where a very small number of incoming calls may have been transmitted with incorrectly formatted, missing, or invalid CLI.<br /><br />We believe this has now been resolved but are monitoring the affected interconnect closely.</p> Mon, 22 Oct 2018 20:27:15 +0000https://status.simwood.com/incidents/r94fqv1dvxth
https://status.simwood.com/incidents/r94fqv1dvxth