Customers can’t sign in: rehearse an authentication-provider outage

Your project management platform is running, but new customers cannot sign in. Support is receiving messages, engineering is investigating and the supplier has acknowledged a disruption without giving a recovery time.

Some customers can still work. Others cannot reach their projects. The team needs to decide what to check, what to say and what options are actually available.

A short tabletop exercise lets colleagues rehearse those decisions before a real incident puts them under pressure.

The UK Defence connection

The UK Ministry of Defence’s 2017 Wargaming Handbook describes using wargaming to explore decisions, including in planning, education and training. A useful principle for tech is that participants make choices and then examine how a developing situation affects those choices.

The session below is a simplified tabletop adaptation inspired by that approach. It is a discussion exercise, with new information introduced in stages. It does not predict how an outage will unfold or prove that a recovery process works.

A software-company scenario

For this example, a software company provides a project management platform. It uses an external authentication provider: the service that checks a person’s identity during sign-in. New sign-ins begin failing one morning.

The exercise assumes that some existing application sessions, which keep people signed in, continue to work initially. Later, those customers are asked to sign in again and become affected too. Treat that as a scenario detail to check against your own system. Session behaviour depends on the application and its configuration.

Invite an engineer familiar with sign-in, a support colleague and the person responsible for coordinating the incident. Include the supplier contact and someone authorised to assess access-control decisions. Choose a facilitator and a note-taker; a small team can combine roles.

Discuss the scenario without changing production settings. Before starting, agree which capabilities and recovery arrangements exist, which have been tested and which remain unknown.

Run the exercise

Minutes 0–5: set the scope

Purpose: Agree the customer journeys and decisions the exercise will cover.

Write one objective: “Explore how the team will respond when customers cannot sign in through our authentication provider.” The aim is to reveal gaps in the response, rather than test who can answer fastest.

Identify the journeys that matter: a fresh sign-in, a customer already using the platform and a customer asked to sign in again. Ask engineering what is known about each. Give participants a written route to contribute, and keep assumptions visible throughout.

Minutes 5–12: introduce the outage

Purpose: Establish impact and agree the first customer update.

First update: new sign-ins are failing. Some customers already using the platform still have access. The provider reports a disruption but no recovery estimate.

Who coordinates the response and contacts the supplier? What evidence will engineering gather to understand the affected journeys? Who approves a customer message, and where can people read it without signing in? Agree when to issue the next update, even if there is no new recovery estimate.

Keep the message within the evidence available. “Some customers cannot sign in” is different from saying the whole platform is unavailable or promising that no work has been affected.

Minutes 12–22: widen the impact, then test recovery

Purpose: Rehearse access decisions and the evidence needed to close the incident.

Second update: customers whose application sessions end are now affected too. A customer asks support for another way into their account. Who can assess that request, and what approved options really exist? A suggestion to bypass normal sign-in or identity checks needs scrutiny; urgency does not make it an acceptable fallback.

If no approved alternative exists, record that limitation and agree how support will explain it. Discuss support capacity and consistent wording so colleagues are not making separate promises under pressure.

Third update: the provider reports recovery, but support still has reports of sign-in failures. What will engineering check before the team announces restoration? Include the affected sign-in journeys and access to the correct customer workspace. Record any remaining failures, who investigates them and who decides whether the incident can close.

Minutes 22–30: debrief and assign

Purpose: Turn uncertainty into specific follow-up work.

Ask where participants lacked evidence, authority, a contact or a usable process. Did someone rely on a recovery option that has never been tested? Could customers reach the incident update without access to the platform?

Give each agreed action an owner and a place in the work plan. That might mean reviewing supplier escalation details, preparing customer-message guidance or separately testing recovery checks in an authorised environment. A tabletop can identify these needs; discussing a recovery path does not demonstrate that it works.

A decision record you can use

What to try next

For your first exercise, keep the scope to one dependency and use this suggested 30-minute structure as a starting point. Adapt the updates to your architecture and the responsibilities your team actually holds.

Before finishing, choose one response gap to address and agree how the team will check the change. The useful result is a clearer, tested response to bring into the next incident.

Sources: UK Ministry of Defence, Wargaming Handbook (2017); Auth0 Support: session management and staying logged in. The software-company scenario and exercise are Coded Female adaptations.