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 prioritise 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: Linking root cause analysis to problem tickets turns scattered post-mortem notes into a backlog somebody can actually work.
Greg: It keeps the root cause sitting alongside the related incidents and changes, so the pattern is visible rather than reconstructed later.
Anna: It also leaves an audit trail, which compliance reviews will ask for eventually.
Greg: And it puts the improvements into planning sessions, competing for time like everything else, instead of living in a document nobody opens.
Anna: Two questions worth asking your own team. Where do past RCAs live, and who actually reads them?

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: Five ways this drifts. Forgetting to link the ServiceNow record and the GitHub issue, so the two accounts of the same problem slowly diverge.
Greg: Vague problem statements that hide the business impact, which makes prioritisation impossible.
Anna: Issues left open for months with no clear owner, which is how a backlog becomes an archive.
Greg: Urgent hotfixes applied outside the process and never documented, so the next person meets the same surprise.
Anna: And reviewing status only once. Lessons fade quickly without a second look.

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.