instance down

[davidrb84]

Hi guys, looks like our instnce is down

 

[James Ainsworth]

Hi David,

I just wanted to make sure that your have raised this through the standard support process on https://www.hornbill.com/support?  

Regards,

James

[davidrb84]

Hi James,

 

My understanding is that with out service plan (essentials) we should be reporting through here.

 

Certainly we have the last 10 outages. Happy to be corrected :-)

[James Ainsworth]

Hi David,

I've run a check and from my connection I'm not getting any errors on your instance.  Are you able to check that status via a connection that is outside your network?

[davidrb84]

Looks working again now.

I've always assumed the /support test was run server side rather than from my connection?

[James Ainsworth]

That's great news David.  It is possible that the instance is server side, I just wasn't sure why we were getting different results.  Most importantly, you are up and running   

[James Ainsworth]

47 minutes ago, davidrb84 said:

My understanding is that with out service plan (essentials) we should be reporting through here.

Hi David,

Yes, that is correct.  I hadn't check your plan before making my comment.  

[Victor]

21 hours ago, davidrb84 said:

I've always assumed the /support test was run server side rather than from my connection?

@davidrb84 @James Ainsworth Not quite... so, just to clarify a few things regarding the Status Check:

Some of the tests are indeed run on the "server" (is not technically the correct term but for simplicity let's call it that) but not all. As with any Cloud service the "client" will be the user browser while the "server" will be wherever the service platform resides. There is communication between the two. This how this work (a brief description):

• the browser (client) sends a request to the service (server)
• the service process the request
• the service sends back a response to client's request

Only the second happens entirely on the service (server) side. The other two always have a client component involved. Therefore is important to test the service from where the service is intended to be used (user location) to show if there is a comms problem at first or third stage or if there is an issue on the second stage which is completely independent of the user.  There is some information about this here: https://wiki.hornbill.com/index.php/Service_Availability_Check however it does not detail on all the individial tests performed nor should one be too worried about them. The details presented there are more important to us (Hornbill) to understand where a possible failure is.

Now if we look on the details of a successful test and the one where there were failures yesterday, we can see the failure at the SQL tests (more precisely the HTTP SQL tests) which means there was an issue connecting to the SQL database. Now this is an internal mechanism to Hornbill service meaning the issue lays entirely on Hornbill and has nothing to do with the user. It just happened that James run the test himself after the issue was corrected (unknowingly at the time) otherwise he woudl have also seen the failure. Now, to give you a different example, if the failure would have happened at the, let's say, "Initial Connection" test then this could very well indicate an issue at the user side (or in transit), where the user browser is unable to connect to the service. Hope this gives some clarification on how this works overall  

[davidrb84]

Thanks @Victor as always a detailed response!

That was more or less as I would have expected. The only exception being I would have thought the support check wouldn't have included "my" client to server communications, rather a 'virtual' client in a known state.

Interesting to know though, thankyou!