Known error example

Scenario

A mid-size professional services firm runs a customer portal that authenticates through corporate SSO (SAML). Over three weeks, the service desk logged twelve incidents where users intermittently failed to sign in between 08:00 and 09:30 on weekdays. Each incident was restored by asking the user to retry, clear cookies, or wait a few minutes. Business impact grew: consultants could not reach client files at the start of the day.

After the fourth recurrence in one week, problem management raised a record, linked the incidents, and investigated. Root cause was confirmed; a workaround was published for the service desk while a permanent fix went through change.

Example known error record

Identity

• Problem / known error ID: PRB004182 (known error)
• Title: Intermittent SSO sign-in failures on customer portal at peak
• Status: Known error — workaround published; permanent fix in change
• Owner: Don Francis (Problem Manager), technical lead: Identity platform
• Services / CIs: Customer portal, SSO IdP, portal web tier
• Linked incidents: INC10401–INC10412 (and ongoing matches)

Symptoms

• Users report “sign-in failed” or endless redirect after choosing corporate SSO
• Mostly weekday mornings 08:00–09:30; rare outside that window
• Retry after 2–5 minutes often succeeds without a password reset
• IdP health dashboard shows brief spikes in SAML response latency, not a full outage
• No consistent browser or device pattern once cache/cookie advice is excluded

Root cause

The portal’s SAML assertion consumer service shared a connection pool with other outbound HTTPS calls. Under morning peak, the pool saturated. New SSO callbacks waited or timed out while the IdP was healthy. Chronological analysis of pool metrics against incident times, plus a controlled load test, confirmed the cause. This is a capacity and design defect in the portal tier, not an IdP outage.

Workaround

• Service desk: Advise a single retry after two minutes. If still failing, use the portal’s “break-glass” local login path (named accounts only) and log the incident against PRB004182 — do not reset the corporate password as first action.
• Operations: If more than five related incidents in fifteen minutes, restart the portal web pool workers during the change window defined in the runbook (temporary relief; expect recurrence until the permanent fix).
• Communication: Status page note when a morning cluster is active; remove the note when the spike clears.

Permanent fix and change link

• Change: CHG009551 (normal) — separate SSO callback connection pool, raise pool limits, add saturation alerts
• Risk: Medium; requires portal web tier restart in a maintenance window
• Target: Next CAB-approved weekend window
• Verification: Load test of SSO callback path; alert on pool wait time; watch morning incident rate for two weeks after implementation

Knowledge and closure intent

The known error stays visible until CHG009551 is implemented and post-implementation review confirms the morning cluster has stopped. The problem owner then closes the known error, leaves a short knowledge article for historical search, and confirms linked incidents use the new category only if a different failure mode appears.

Why this record works

• symptoms are written for the service desk, not only for engineers
• root cause is specific enough to drive a change, not a vague “SSO issues”
• workaround limits harmful first actions (unnecessary password resets)
• change and verification criteria are explicit so the known error has an exit path