/ Status Updates

As reported over the last 30 days, in weekly emails, we have been announcing about our disabling of history for customers who have not enabled this service in the account dashboard directly.  This means requests to Storage API will return a response explaining that messages are not being stored and that you must visit your account dashboard to enable PubNub Storage.  Please be sure to connect with PubNub help@pubnub.com directly if there are any emergencies that need attention regarding this update.

Full steam ahead!

On 2013/02/22, between 00:12 and 00:27 GMT, the PubNub Network, for some customers in the US and Europe, experienced occasional Latencies and errors; with latencies exceeding normal message delivery speeds.  The majority of the errors were resolved by 0:22GMT and the all remaining issues were fully resolved by 0:27GMT.

On February 3rd, 2013 at 4:42pm to 4:54pm Storage API Reads were delayed and a percentage of traffic experienced intermittent responses for twelve minutes.  Storage Writes were not affected.  Note that the Storage API Read service is back to normal operation.  All other PubNub services were not affected.

Tonight, Jan 27th, Storage Read API was slow or unreachable for six minutes between 10:06pm and 10:12pm PST.  Normal operation of the Storage Read API has been restored.  Note that this did not affect other services in the PubNub Network.

Jan 26th between 10:19PM - 10:58pm PST PubNub History API was periodically inaccessible to a minority of requests.  History Write operations continued as normal and messages were saved as normal. Note the History Read API have returned to normal operating status.  This disruption did not affect any other PubNub services.

On January 24th between 7:48am - 8:08am PST a service disruption occurred for twenty minutes where History Read operations became unavailable. History Write operations continued as normal and data save process was unaffected. Note the History Read Service have returned to normal operating status.

On January 24th between 10:35am and 10:44am PST Pingdom incorrectly reported downtime for nine minutes. There was NO DOWNTIME. A bug with the Pingdom console and the Google Chrome browser caused a Pingdom config option to be set incorrectly. A switch was flipped which triggered an alert that caused an incorrect disruption status. Note that the test was repaired and the uptime report graphs shows normal status. We have an outstanding ticket with Pingdom to resolve this issue.