UmbraCare LOGO

Umbraco Session Timeout Configuration and Security

Sometimes even the simplest settings deserve a second look. Umbraco’s session timeout appears straightforward in the documentation, but I decided to investigate what actually controls it and how far it can be safely tuned.

Umbraco
Published on: , by:
Piotr Bach picture
Piotr Bach
Wojciech Tengler picture
Wojciech Tengler

Jump to Section

Why I looked under the hood

We were rolling out a timeout change across all environments. Our Umbraco editors spend hours working in the back office, but the default 20-minute setting kept signing them out right in the middle of their work. I’d changed TimeOut before, but this time I wanted certainty - what exactly controls sign-out and how far I can push it without surprises.

Umbraco 13 login panel after session timeout

Umbraco 13 login panel after session timeout

The documented switch that actually affects the back office

Umbraco reads the idle timeout from Umbraco:Cms:Global:TimeOut inside your appsettings.json. The value is parsed as a TimeSpan (official docs):

"Umbraco": {
  "CMS": {
    "Global": {
      "TimeOut": "00:20:00"
    }
  }
}

This single value defines how long Umbraco keeps your authentication cookie alive before forcing re‑login.

Umbraco 13 session timeout setting in project appsettings.json

Umbraco 13 session timeout setting in project appsettings.json

Where the TimeOut setting lands in code

The timeout maps to a TimeSpan on the global settings model, which is why both hh:mm:ss and d.hh:mm:ss work.

If you like to see where it connects in code:

GlobalSettings.cs (release‑13.11.0)

internal const string StaticTimeOut = "00:20:00";

/// <summary>
///     Gets or sets a value for the back-office login timeout.
/// </summary>
[DefaultValue(StaticTimeOut)]
public TimeSpan TimeOut { get; set; } = TimeSpan.Parse(StaticTimeOut);

TimeSpan: what’s “too long”?

Because TimeOut is a TimeSpan, you’re not limited to hours.

Days are valid via d.hh:mm:ss:

  • 10 days → "10.00:00:00"
  • 30 days → "30.00:00:00"
  • 1 year → "365.00:00:00"

There’s even a theoretical max for TimeSpan (10675199.02:48:05.4775807). I found an interesting discussion on Stack Overflow about why that is - and, out of curiosity, I tried putting that value into Umbraco, but it didn’t work ;)

SO thread: Why 10675199.02:48:05.4775807 TimeSpan maximum…

Dev flow > security - long live convenience😊.

Timeouts should reflect how people actually work:

User Type / Context Suggested Timeout Why does it make sense
Developer 08:00:00 – 2.00:00:00 Keep the flow while building, testing, and context‑switching.
Content Editor / Copywriter 03:00:00 – 08:00:00 Long editing waves without re‑auth.
Manager / Occasional User 01:00:00 – 02:00:00 Reviews and approvals, not marathon sessions.
Shared / Public Machine 00:15:00 – 00:30:00 Enough to fix a typo. Short by design.

Practical tip: Start in the middle of the range, ask editors after a week, and then make adjustments.

Should DEV, STAGING, and PROD use the same timeout?

Important: Umbraco:Cms:Global:TimeOut is an application‑level setting, so it’s global for the whole instance. There’s no per‑user or per‑role timeout.

Environment Suggested Timeout Why does it make sense Risks / Notes
Development 08:00:00 – 2.00:00:00 Keep devs in flow while building and debugging. Low exposure. Short timeouts add no value here in most cases.
Staging / UAT Mirror PROD or +1–2h cushion Realistic editorial testing beats theoretical security. Avoid “it worked in UAT but logs me out live.”
Production - Editors 03:00:00 – 08:00:00 Supports natural writing/review cycles without nagging. Pair with device screen‑lock and awareness.
Production - Managers 01:00:00 – 02:00:00 Fits occasional reviews and approvals. Shorter sessions reduce unattended risk.
Production - Shared/Public 00:15:00 – 00:30:00 Short by design - reduces exposure on shared devices. Communicate the policy to avoid surprise logouts.

❌The confusing key I ran into in the repo

While scanning the Umbraco codebase, I noticed a minutes‑based key in the template config:

"Global": {
  "TimeOutInMinutes": 20,
  "UseHttps": false
}

It’s easy to mix them up. In my checks, this key didn’t drive back-office sign‑out. The value that mattered was still Global:TimeOut. I didn’t have time to dig deeper into what this setting actually does - maybe I’ll check it out someday.

For reference, here’s the exact spot: appsettings.template.json (release‑13.11.0)

Closing thought

Security should protect the work, not interrupt it. Pick a Timeout duration that matches how your team actually edits content, then write it down so everyone knows what to expect.

In our experience, once the expectation is clear, people stop fighting the CMS and start trusting it. Longer sessions can be safe if the basics are respected and the team knows when to lock a screen - that awareness often matters more than the exact number of minutes.

↑ Top ↑