Problems

An incident records a service interruption and its response. A problem records the underlying issue that may require longer investigation. Name the service, write a clear problem statement and assign an owner. The problem can remain open, move into investigation, become a known error or be resolved. Its root cause text should explain the finding in terms that a future responder can use.

A cluster observation or incident update may motivate the problem, but the problem record has its own owner and status. The service link lets a Service Owner review the longer thread alongside current incidents without treating every resolved incident as a solved root cause.

• Identify. Service Owner creates a problem statement for the affected service.
• Investigate. The named owner records root cause findings as they become reliable.
• Resolve. The owner updates the status when the cause has been addressed or a known error needs tracking.

The problem investigation view shows active work and known errors with their owner. During an incident, the responder can use it to identify a recognized issue. A known error does not mean the current incident is resolved; the responder still needs to check the actual service condition.

Decide when repeated incidents warrant a problem, how a problem owner is selected and what evidence is sufficient for a root cause statement. Agree on the meaning of known error for your team. It should point to a understood condition and next action rather than becoming a holding status for work nobody owns.

Where a fix requires operational work, prepare a separate change. The change reviewer needs the planned window, risk and rollback plan. The problem owner can assess whether the verified change addresses the root cause, while the incident responder independently checks whether the affected service has recovered.

The checkout workload loses readiness on several mornings. The Service Owner creates a problem for the affected service and names the investigating person. They review incident updates and dated observations, then record a root cause when the pattern is understood. A Platform Operator drafts a change to address it.

After approval and implementation, compare later observations with the earlier pattern. The problem owner can then record whether the root cause is resolved. The open incidents still need their own resolution entries and assigned responders. This separation keeps a broad fix from silently rewriting the history of individual service interruptions.

• Problem investigation — Review open, investigating and known-error records by service and owner.
• Active incident board — Check current response work that may be related.

Use problem to change to test the handoff from diagnosis to reviewed action.