DSB: How to keep the website up during extreme traffic peaks


On 23 December, Denmark was badly hit by a snow storm. DSB, Danish Railways, worked hard to get passengers to their destinations on the busiest travel day of the year. The combination of inclement weather and a very busy day, forced the company website,, to its knees.

Many organisations experience extreme traffic peaks on their website, sometimes expectedly; sometimes unexpectedly. I had a conversation with Thomas Jørgensen, system owner for the website in DSB's IT department. Thomas shared several crucial lessons learned on how to keep a busy site with regular peaks up and running, while also having prepared for when the unexpected happens.

The DSB website traffic challenge

DSB is the major rail operator  in Denmark, so its website is generally a busy one. The website traffic pattern has its expected and regular ups and downs based on rush hour and holiday periods.

From a process perspective, Thomas told me that their work to address the traffic challenge is divided into 2 separate streams:

  1. Preparing carefully for when peaks are likely to happen, e.g. for busy travel days
  2. Unexpected peaks which require action straight away, e.g. for emergencies such as if a train got stuck somewhere on a bridge or in a tunnel

For the unexpected traffic peaks, the communication department operate a 24/7 hotline. In case of an emergency, the communication department can activate a special emergency frontpage without the usual digital marketing campaigns at the click of a button.

DSB maintains their own hosting infrastructure and actively monitors website performance, enabling them to respond faster in case of issues. The actual website is implemented by Cap Gemini in Sweden using EPiServer as the content management system.

Keeping the DSB website up and running is not just about technology

In my conversation with Thomas, he shared a detailed account of the 23 December crash including both technical and non-technical take-aways. To quote:

You can do everything possible at a technical level, including performance tuning, buying additional hardware and software, but most important to keep the website up are internal processes

Specifically, Thomas is referring to internal communication procedures. The responsible needs to know whom to reach straight away in case of likely trouble ahead. Ideally this should empower the web team when the situation unfolds to make quicker and better decisions.

You still fine tune all the systems, but no matter how much hardware and software you have in place, you are still bound to run into unexpected and extreme peaks that can bring your website to a sudden halt.

DSB website traffic handling to-do list

Thomas shared a high-level listing of the different on-going tasks DSB has in place:

  • Make sure that the technology stack (operating system, database, application server and CMS) used for is tuned for performance to avoid running into bottlenecks
  • Avoid scheduled administrative tasks and routines, e.g. backups and updates, in peak seasons and be prepared to stop these during unexpected peaks
  • Add virtual servers as additional capacity to increase the load that the application servers can handle. This means that for peaks the capacity is significantly larger than normal
  • Have procedures in place with a dedicated responsible person and emergency procedures which are used for unexpected peaks

Finally, DSB keeps static pages ready for emergencies, which we'll take a closer look at below.

The DSB emergency website

DSB maintains ready and up-to-date static pages ready, so that they can quickly be put in place as a replacement to the normal dynamic DSB frontpage. Thomas explained that DSB at regular intervals tries to identify what might cause peaks and consequently what content needs to be on the static emergency page.

This is what the DSB website looks like on a normal day with an approximate 50/50 split between marketing campaigns and booking a ticket: on a normal day - click for large view

Here's how the website looked on 23 December around 13:00 with 0% marketing, a brief explanation that this is an emergency page and relevant links where visitors may be able to find what they were looking for, e.g. is my train still running, book a ticket emergency page - click for large

DSB realized from the start, that the content required on the emergency website will vary from case to case, which is why the communication department has flexibility to easily get relevant text on the site. For service windows for the IT department, the same text can usually be used.

Learn more

Read how Grundfos treats performance as a crucial part of the web experience

Performance, fail over and keeping websites up and humming is a regular theme in our groups, both the business and technical groups.


Janus Boye
CEO and Group moderator

As founder and managing director at J. Boye, Janus has grown the business from an office at home in 2003 to an international operation today with members in Europe and North America.

Janus is a frequent speaker at industry events and chairs the renowned J. Boye Conferences held since 2005 in Denmark and since 2009 in Philadelphia, US. Among the organisations that have recently called upon Janus' expertise are  local government agencies, the UN in New York and companies such as Brother, Carlsberg and Red Bull.

4 Responses to “DSB: How to keep the website up during extreme traffic peaks”

  1. [...] DSB: How to keep the website up during extreme traffic peaks | J. Boye DSB (Danish Railways): How to keep the website up during extreme traffic peaks #snow #traffic #peak – Janus Boye (janusboye) (tags: traffic peak snow) Twitter Updates [...]

  2. Brian Schildt says:

    out of curiosity – how many times a year is it nescessary to enable the emergency website? AND Thomas – Thank you for sharing real life experience! and Janus thank you for articles continiously keeping all of us web pro’s on the toes in our solution deliveries!

  3. Thomas Jørgensen says:

    Hi Brian.

    This does not happen very often and we do our best to learn from these situations. Last year we had two cases where our setup reached it’s limit and we where more or less unresponsive for a couple of hours.

    Thomas, DSB

  4. Runar Standal says:

    Hi Thomas

    Have you considered Cloud computing technologies like Azure in order to automatically adjust your capacity during peak hours? Banedanmark chose Azure for handling this problem with their homepage. With a positive result it might seem:

    Runar Standal, Kraftvaerk

Leave a Reply

Most popular posts from our blog
August 12, 2009 by Janus Boye
Selecting the right CMS is not an easy task with; there is in excess of 1,000 vendors in the very dynamic CMS…
February 16, 2010 by Janus Boye
All modern CMS vendors claim to be capable of delivering content to mobile devices. Some even offer additional modules to make the…
March 21, 2011 by Janus Boye
You may be impressed by some of the features during a CMS product presentation, but in reality many of the features that…
Recent comments
April 8, 2014 by Bertrand
I would include the Apache Sling website in this list ( ) as it's what powers AEM. Understanding the…
April 8, 2014 by Scott Liewehr
Great resource, Janus. And thanks for the mention.
March 15, 2014 by John
Their site may not even be a CMS but more of a custom built web application. Also, how do you…