A web app is usually the first step a brand takes toward marketing itself and its products or services. With nearly 35% of year-end sales now being done online, a Web App for retailers and other businesses is considered as important as their brand identity. For some, their Web App is their brand identity. Web App downtime is an often ignored but a real issue that plague nearly any Web App in the world.
A lot of lessons are learned when a lot of obstacles are thrown at you without a failsafe. One fine day we received a live logistics project consisted of 13-18 running servers. These servers were located in three different regions on AWS. Furthermore, there wasn’t any documentation supporting the project regarding the deployment strategies used.
Neither were there any .pem files that could grant us access to the servers. Nor any information about the server hosting the website or the web app on it. All these things combined made for a challenging situation for the Development and operations team to detect the servers and establishing the website application running on it. The day we received it, it resulted in downtime on the main Web App which was met with immediate attention and corrected within 10 minutes.
What helped us undo the wrong?
The only resources at our disposal were the server credentials and the domain credentials devoid of any keys(.PEM files) to grant us access.
How did we tackle the downtime?
After excluding the first suspect from our list, we proceeded to check the domain and hosting configuration. Our domain hosting server has been acquired from GoDaddy. Once we had logged in we realised that even though we had acquired the domain and its hosting, the DNS however, wasn’t managed from that account. On the contrary, we were using Amazon Route 53. This further led us to a particular server that was the cause of concern.
We create a copy of the running server on which the Web App was hosted. We also found that the hosted Web App was working well when tested with the server locally.
Once we had established the server at fault, we got hold of the DNS. This was followed by replacing the existing server with a copy that was created earlier.
A similar sentiment was echoed last year when we pulled off the near-impossible feat of bringing a Web App with 12,000 subscribers back online in only 3 minutes!
In total, it took us nearly 10 minutes to resolve this downtime incident. With our extensive experience in Web App management and server configuration, we can help you get back online, fast! If you have been grappling with these issues and have questions about Web App downtime, feel free to contact our CTO who can give you expert advice and tips that can help you reduce Web App downtime.
