Back to lesson

RCA Records in ServiceNow & GitHub

Slide 1: RCA Records in ServiceNow & GitHub

On-screen

RCA Records in ServiceNow & GitHub

Because "we'll remember to fix that" are famous last words

Narration

Anna: We've talked about how to run a blameless post‑mortem, but what happens to those findings afterward? We've all seen post‑mortems that become "post‑mortem" themselves—dead and buried in someone's email within a week.
Greg: Exactly. The best place for that information is a ticketing system like ServiceNow. A problem record stores the timeline, contributing factors, and any workarounds so nothing slips through the cracks.
Anna: From there we link follow‑up work in GitHub. Today we'll walk through that flow so you can turn lessons learned into real improvements.

Slide 2: Why link RCA to problem tickets?

On-screen

Why link RCA to problem tickets?

  • Turns scattered post‑mortem notes into an actionable backlog
  • Tracks the root cause alongside related incidents and changes
  • Keeps an audit trail for compliance reviews
  • Helps prioritize improvements during planning sessions
  • Ensures lessons learned drive measurable fixes rather than fading away
  • Questions to ask: Where do we store past RCAs? Who checks them?

Narration

Anna: Why link RCA to problem tickets? focuses attention on a concrete part of the work. Turns scattered post‑mortem notes into an actionable backlog, Tracks the root cause alongside related incidents and changes, and Keeps an audit trail for compliance reviews.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Tracks the root cause alongside related incidents and changes; Keeps an audit trail for compliance reviews; Helps prioritize improvements during planning sessions.

Slide 3: ServiceNow problem records

On-screen

ServiceNow problem records

  • ServiceNow is a ticketing system widely used in IT operations
  • A problem record summarizes the investigation after an incident
  • Include a timeline, contributing factors and workarounds
  • Link any relevant incident tickets, change requests and knowledge articles
  • Assign an owner and set a target resolution date
  • Example: "Checkout failure during Black Friday—DB connection pool exhausted; manual phone orders used as workaround"
  • Good descriptions help managers see impact and approve resources

Narration

Anna: When you create a problem record in ServiceNow, start with a short title that hints at the business impact. Then lay out a clear timeline, the contributing factors, and any workarounds discovered during the incident.
Greg: Link related incident tickets and the change request that eventually fixes the issue. A good record might read, "Checkout failure during Black Friday—DB connection pool exhausted; manual order processing used until 4:30 PM."
Anna: Assign an owner, set a target date, and capture the final resolution. Managers appreciate the audit trail, and the team can easily revisit the record when a similar issue crops up.

Slide 4: GitHub issue references

On-screen

GitHub issue references

  • GitHub issues track code work that addresses the problem
  • Title should mention the ServiceNow number for easy searching
  • Example: "Increase DB connection pool size - PRB0001234"
  • Describe the fix in business terms so non-developers understand
  • Link commits and pull requests back to the issue
  • Close the issue only after the fix is in production and verified
  • Questions to ask: Does this change need a code review? Who signs off?

Narration

Anna: After the problem record is in place, open a GitHub issue for each improvement task. A helpful title might be "Increase DB connection pool size - PRB0001234," not just "Fix database."
Greg: In the description, reference the ServiceNow ticket and explain the business impact. That cross-link lets developers see why the work matters without leaving GitHub. As code changes move through pull requests, mention the issue number so everything stays connected.
Anna: Once the fix is deployed and verified, close the GitHub issue and update the ServiceNow record. Now both systems tell the same story.

Slide 5: Putting it all together

On-screen

Putting it all together

  • Start with a shared post‑mortem document capturing logs and timelines
  • Within 24 hours, create a ServiceNow problem ticket summarizing the findings
  • Open a GitHub issue for each improvement item and link it back
  • Review progress weekly during improvement meetings
  • Update the ServiceNow ticket when the GitHub issue closes
  • Example timeline: incident 2:15 PM, outage 2:45 PM, resolved 4:30 PM; action item implemented two days later

Narration

Anna: Putting it all together starts with a shared document right after the incident. Capture timelines, logs, and team observations while the details are fresh.
Greg: Within 24 hours, summarise those findings in a ServiceNow problem ticket so managers have a clear view. Then create GitHub issues for each action item and link them back to that ticket.
Anna: During improvement meetings, review the problem record and its linked issues to check progress. For example, the outage occurred at 2:45 PM, was resolved by 4:30 PM, and the fix was deployed two days later. Keeping that timeline in one place ensures nothing from the RCA gets forgotten once the incident fades.

Slide 6: Common pitfalls

On-screen

Common pitfalls

  • Forgetting to link ServiceNow and GitHub so records drift apart
  • Vague problem statements that hide the real business impact
  • Issues left open for months with no clear owner
  • Urgent hotfixes applied outside the process and never documented
  • Reviewing status only once, so lessons fade quickly

Narration

Anna: Common pitfalls focuses attention on a concrete part of the work. Forgetting to link ServiceNow and GitHub so records drift apart, Vague problem statements that hide the real business impact, and Issues left open for months with no clear owner.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Vague problem statements that hide the real business impact; Issues left open for months with no clear owner; Urgent hotfixes applied outside the process and never documented.

Slide 7: Key takeaway

On-screen

Key takeaway

  • Integrated records keep teams aligned and accountable
  • ServiceNow captures the process while GitHub tracks the code
  • Clear links turn each incident into documented learning rather than another "we should totally fix that someday" conversation

Narration

Anna: Integrating your RCA notes with ServiceNow and GitHub keeps everyone on the same page, from engineers fixing code to managers tracking risk.
Greg: It also helps during audits or handovers because every decision and follow‑up lives in one place with clear links to the code changes.
Anna: When teams consistently link these systems, improvements actually get implemented instead of disappearing into a folder.
Greg: That habit turns each incident into documented learning rather than another "we should totally fix that someday" conversation.
Anna: Plus, seeing past action items accomplished builds trust and motivates the team to keep improving the process.