I know that this the page is called every 15 minutes (by default) by a scheduled task.

<agent type="Sitecore.Tasks.UrlAgent" method="Run" interval="00:15:00">
  <param desc="url">/service/keepalive.aspx</param>

Does it have any other purpose than keeping the application pool from timing out and make sure other scheduled tasks are run?

Can the same not be achieved by setting the application pool idle timeout to 0 in IIS?

6 Answers 6


Purpose of keepalive.aspx

Here's the full code of the page in Sitecore 8.0:

<%@Page Language="C#" %>
<%@ Import Namespace="Sitecore.Analytics" %>
<!DOCTYPE html>
<head id="Head1" runat="server" enableviewstate="false">
  <title>Keep Alive</title>
  <script runat="server">

      protected override void OnPreInit(EventArgs e)
          Tracker.Enabled = false;

  <form id="form1" runat="server" enableviewstate="false">
    Keep Alive Page

In Sitecore 8.2 it's even shorter:

<%@Page Language="C#" %>
<!DOCTYPE html>
<head id="Head1" runat="server" enableviewstate="false">
  <title>Keep Alive</title>
  <form id="form1" runat="server" enableviewstate="false">
    Keep Alive Page

It's pretty clear this page doesn't do anything meaningful—it even has no code behind.

So its purpose, indeed, is to keep the application pool alive.

Extending Sitecore client sessions

As G Killian has discovered, this page is also regularly requested from JavaScript to extend browser sessions of users logged into Sitecore Desktop. Image source requests to this page ensure that the user won't be logged out from Sitecore provided that they keep their browser open. A great find!

Disabling IIS pool recycling

Yes, you can (mostly) disable automatic IIS pool recycling, although it is a bit more complex than just removing the idle timeout. See more in this answer:


I believe Sitecore included its own keep-alive mechanism because IIS does recycle apps by default, and Sitecore wanted to override that behavior out of the box.


Adding to Dmytro's answer - indeed the KeepAlive.aspx serves to keep a heartbeat running.

While in most cases this is the equivalent of setting the idle session timeout to 0, there are cases where you could end up with a shutdown of the Asp.Net worker process - idle timeout or keepalive alike.

Your worker process may terminate due to a number of reasons, including High Exception Count, Memory problems, Machine.config changes and so on. If this happens, the site will need a kickstart from an external source - as Sitecore won't be alive to keep itself alive.

An example of this can be found in: How to keep Alive your Sitecore instance 24X7?


I personally think the KeepAlive page is there for people who don't understand or haven't bothered to tune their IIS application settings.

Even with the KeepAlive page, if your site sits idle for 29 hours it's going to turn off if you haven't touched those default settings. That may be a problem if you have a Job Server that never fields requests. So, it behooves you to go in there and think about what those switches need to be set to.

I don't think there's any harm in keeping it there, though.


I don't know that your question needs more than 4 answers, maybe you've got what you wanted, but I do have another aspect not previously mentioned :) -- so let me add yet another answer. The KeepAlive.aspx page is also used for extending active sessions in the Sitecore Client (and prevent a timeout from spoiling a long duration form edit for a content author, for instance).

I explain this a bit at "Understanding Sitecore Session Timeouts" -- https://grantkillian.wordpress.com/2015/03/26/53/ -- but you can see this explicitly if you view the source of sitecore/shell/controls/Sitecore.js in the scKeepAlive javascript function (for example, line 1988 in my Sitecore 8.1 rev 151207 install):

function scKeepAlive() {
    var img = document.getElementById("scKeepAlive");
    if (img == null) {
        img = document.createElement("img");
        img.id = "scKeepAlive";
        img.width = "1";
        img.height = "1";
        img.alt = "";
        img.style.position = "absolute";
        img.style.display = "none"; /* if set to "", causes scrollbars in firefox */   
    img.src = "/sitecore/service/keepalive.aspx?ts=" + Math.round(Math.random() * 12361814);

A short while before a session expires this javascript code requests [webroot]/sitecore/service/keepalive.aspx to extend the session. This is wired up in the scSitecore.prototype.onLoad function: window.setInterval(scKeepAlive, keepAliveTimeout)

  • A great find! This makes a lot of sense, too :) Commented Oct 18, 2016 at 13:45

This is the reason it's there yes, it is so:

  • Scheduled tasks run as expected, even when traffic is low / non-existent
  • There is no delay hitting the site if the application pool has recycled - so no building up caches etc.

Could you achieve the same thing with setting the application pool idle timeout to 0?

Technically, I suppose you could - I've been having a dig around for best practices on this and opinions are split.

Most people say that the timeout is good to prevent:

  • leaky applications
  • servers with lots of application pools

But for Sitecore, the keepalive will force connections to say alive regardless, so it wouldn't solve leaky applications and you're unlikely to have lots of application pools on the production servers.

I'd be interested to see other people's answers on this too.

  • "There is no delay hitting the site if the application pool has recycled" — but keepalive.aspx will not be hit automatically after a pool recycle. Or do you mean that one can request it manually or from an external service? Commented Oct 17, 2016 at 10:33
  • This is more about preventing it dying as opposed to it bringing back to life after an AppPool recycle - which, as you say, won't fire until something brings Sitecore back to life (like an external service) Commented Oct 17, 2016 at 10:37

Besides what has been mentioned on the other answers it can be useful if you have a load balancer and you want to configure a page where the load balancer can ping sitecore to know if the node is up or not. It can be done with other pages yes but I generally use this one

  • 1
    Good point, Diego, and I know companies who do use this page as a lightweight request as a "proof of life" for load balancers -- but most enterprise load balancers I know prefer a simple string output such as "SUCCESS" or "FAILURE" vs parsing the HTML markup to get a response. I think this is a very trivial distinction that won't matter to many, but since this has become the most thorough documentation on the Sitecore KeepAlive page I'm adding this pedantic note :)
    – G Killian
    Commented Oct 18, 2016 at 13:42
  • you are right G Killian. I've seen this being done with robots.txt, with a page with a string as well and keep alive. they all work fine :)
    – Diego
    Commented Oct 18, 2016 at 13:46
  • For this particular usage, Diego, I recommend the Heartbeat.aspx as it will do an actual check of the connection strings and make sure the app can connect to the back-end. Commented Oct 18, 2016 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.