This is actually a server issue. Kickstart works by having your browser visit the same URL repeatedly through AJAX to perform each extraction step. This is necessary since the extraction would otherwise take too long to complete which would cause your server to abort it, or simply run out of memory, reporting an error. By separating the work in smaller chunks we can perform the time, disk and memory intensive process of extracting a backup archive over a web interface. However, this may cause different issues on some servers.
First of all, some servers impose limits on the amount of resources (CPU, disk, memory) your hosting account can use in a specific period of time. These limits are there to protect the server against abuse by malicious tenants or scripts with coding mistakes which result in very high resource usage. By its very nature, Kickstart needs to do “heavy work”. It has to read a rather big backup archive, decompress the data in memory and write it into the thousands of files which make up your site. This requires a lot of disk and CPU activity to take place and do take up a substantial amount of memory. This may indeed trip the server protection. Tech talk (for IT pros): this is usually implemented either with Linux ulimit settings or through configuration of the virtualization environment (e.g. CloudLinux) under which your hosting account runs.
Second, some servers may have a built in Denial of Service protection. They keep track of which IP address is visiting which URL. If the same IP address tries to repeatedly access the same URL they treat is as a potential Denial of Service and may either simply reject the request or ban the IP address for a while. If this happens you will probably be unable to connect to your site for anywhere between a few seconds to a few hours. Unfortunately there is no way to know that in advance because, for security reasons, do not publicize this information. Tech talk (for IT pros): this is usually implemented on Apache using mod_evasive.
Finally, some servers may be filtering requests based on what kind of information is being sent. If they think that the data being sent to the server looks dissimilar to typical web traffic they might either just reject the request or ban the IP address for a while. PHP, the language Kickstart and your site's software is written in, is stateless. This means that it doesn't remember what happened between two successive requests. Extracting a backup archive requires a way to remember state, for example to track of how much of the archive we have already extracted, where to extract it and other options you made in Kickstart. To this end, Kickstart sends its state in an encoded form to your browser after an extraction step is complete. Your browser will then send it back to Kickstart when it asks it to run the next extraction step. The state is a rather long bit of encoded data which does indeed look dissimilar to regular web traffic. This may trip up the server protection discussed above. Tech talk (for IT pros): this is usually implemented on Apache using mod_security2.
The first two issues can be worked around using the first two options (time settings) in the Fine Tuning section of Kickstart's interface. You can set the minimum execution time to 5 and the maximum to 1. This is not a typo! It creates a 20% duty cycle: Kickstart extracts files for 1 second and then waits, doing nothing, for another 4 seconds so that the time between requests is the configured maximum, 5 seconds. Some servers might not like the predictability of the requests' timing. If this is the case try setting a minimum of 5 and a maximum of 10. This means that Kickstart will work for 5 to 10 seconds before telling your browser to run the next extraction step. This uses more resources, makes the extraction faster and introduces some variance in the time it takes each extraction step to run. If none of these settings work for you the server may be configured with very tight settings. In this case you can extract the backup archive on your computer, using Akeeba Kickstart, and upload all extracted files to your site. Then you can complete the restoration by visiting the /installation/index.php on your site.
The last issue cannot be worked around by you. You can try asking your host for a temporary way to disable that server protection. It's possible that your host may be unable to help you if you are not on a VPS or dedicated server. In this case you can extract the backup archive on your computer, exactly as described in the previous paragraph.