Infrastructure Change Impact Assessment Kit

Map infrastructure changes to user impact using Honeycomb and Sentry.

Introduction

30 Second Summary

When your platform team announces an infrastructure change, you need to quickly assess whether customers will feel the impact. Without a structured approach, user-facing risks slip through unnoticed until they become support tickets and churn.

In this project, you will build a reusable Impact Assessment Kit in Google Docs that maps any infrastructure change to customer-facing risk. You will use your existing Honeycomb and Sentry dashboards to ground the framework in real observability signals.

What You'll Build

A comprehensive Infrastructure Change Impact Assessment Kit in Google Docs that serves as your go-to reference when your platform team proposes changes.

By the end of this project, you'll have:

A Change-to-User Impact Chain mental model that maps any infrastructure decision through four layers to business risk.
A structured Impact Assessment Template with blast radius, NFR impact, risk scoring, and communication decision sections.
An Observability Signal Map that translates Honeycomb SLO burn alerts and Sentry User Misery metrics into customer-facing language with clear action thresholds.
Secret Mission: Apply the framework to a real upcoming change on your team's roadmap and draft the customer impact brief.

Are there any prerequisites?

You should have a basic understanding of CI/CD and containerization. You also need read access to your team's Honeycomb and Sentry dashboards so you can reference real data throughout the project.

Set Up Your Assessment Kit Document

Before you can assess anything, you need a home base. A single, well-structured document that lives in your workflow and travels with you into sprint planning, change reviews, and post-incident discussions.

In this step, you will create that document and ground it in reality by capturing a snapshot of your team's current observability posture. This baseline is what makes your framework practical instead of theoretical.

In this step, get ready to:

Create and structure your Impact Assessment Kit document in Google Docs.
Capture your team's current Honeycomb SLO and error budget baseline.
Capture your team's current Sentry Apdex and User Misery baseline.

Create your Assessment Kit document

Your kit needs a clear structure so you can find the right section quickly during a live conversation. Four sections cover the full workflow: understanding the change, assessing the change, monitoring the change, and learning from a worked example.

Open Google Docs and create a new blank document.
Title the document Infrastructure Change Impact Assessment Kit.
At the top of the document, write a brief intro paragraph explaining who this is for and when to use it. Cover three situations: before sprint planning, during change reviews, and after incidents.
Below the intro, create four section headings using Heading 2 style:
Change-to-User Impact Chain.
Impact Assessment Template.
Observability Signal Map.
Worked Example.

What goes in the intro paragraph?

Keep it to 2-3 sentences. Something like: "This kit helps you assess any proposed infrastructure change for customer-facing risk. Use it before sprint planning to flag risky changes, during change reviews to structure your questions, and after incidents to identify what signals you missed."

The audience is you and anyone on your team who bridges platform engineering and customer success.

Use a consistent heading structure

Using Heading 2 for each section keeps the document navigable via Google Docs' built-in outline panel. Click View then Show outline to enable it.

Capture your Honeycomb baseline

Your framework will reference real SLOs and error budgets throughout. Capturing the current state now gives you a concrete anchor point for every assessment you run later.

Switch to your team's Honeycomb dashboard.
Navigate to the SLOs section.
Identify which SLOs are currently defined for your team's services. Note each one by name.
For each SLO, note which edge service it measures. Edge services are the services closest to your end users, where latency and errors are felt first.
Check the current error budget status for each SLO. Note the percentage remaining and how much of the budget period has elapsed.
Return to your Google Doc and add a subsection titled Current Baseline below the four main headings.
Record what you found: the SLO names, the edge services they measure, and the error budget status.

What is an error budget?

An error budget is the amount of unreliability your service is allowed before it violates its SLO target. Think of it like a savings account for reliability. Every failed request or slow response "spends" from the budget.

If you are at 50% budget remaining with 50% of the month gone, you are on track. Below 30% remaining means your users are accumulating bad experiences faster than planned.

Why measure close to the user?

Honeycomb's best practice is to place SLOs on the edge service closest to end users. This ensures you are measuring what customers actually experience, not what your internal systems report to each other.

If your team's SLOs are on internal services rather than edge services, note that as a gap. It is something worth raising with your platform team.

Can't find SLOs in your Honeycomb dashboard?

SLOs require Honeycomb Enterprise or Pro plans. If your team does not have SLOs configured, note that as your baseline finding. Write down which services your team monitors and what alerts exist instead.

Help me figure out where my team's reliability targets are tracked if not in Honeycomb SLOs.

Capture your Sentry baseline

Sentry gives you the user-facing side of the picture. While Honeycomb tracks reliability against targets, Sentry quantifies how many real humans are frustrated right now.

Switch to your team's Sentry dashboard.
Note which projects and services are tracked in your Sentry organization.
Navigate to the transaction summary for your most critical user-facing transaction.
Find the current Apdex score. This ranges from 0 to 1, where 1.0 means every user had a satisfactory experience.
Find the current User Misery count. This counts unique users who experienced load times 4x the satisfactory threshold.
Check for any active performance issues flagged by Sentry (N+1 queries, slow DB queries, endpoint regressions).
Return to your Google Doc's Current Baseline subsection.
Record: the tracked projects/services, your Apdex score, your User Misery count, and any active performance issues.

What do Apdex and User Misery actually tell you?

Apdex is an industry-standard satisfaction score. Above 0.9 means most users are satisfied. Between 0.7 and 0.9 means tolerable but degraded. Below 0.7 means users are actively frustrated.

User Misery goes further by counting actual humans affected. A rising User Misery count after a deploy means real people are having a bad time. These two metrics together give you a concrete "before" picture you can compare against after any infrastructure change.

Not sure which transaction is your most critical?

Look for the transaction with the highest traffic volume that directly serves end users. Common examples: a login endpoint, a dashboard page load, or a checkout flow. If your team has defined key transactions in Sentry, start there.

Help me identify which Sentry transaction to use as my baseline.

Your doc should now have a clear structure with four empty sections and a Current Baseline subsection filled with real data from your team's observability tools.

✔️ I've got my doc structured and baseline captured

Great. Double check that your Current Baseline subsection has data from both Honeycomb and Sentry. You will reference these numbers in Step 4 when building your Observability Signal Map.

ⓧ My team doesn't use one of these tools

That is fine. Fill in whichever tool you have access to and leave a placeholder note for the other. The framework still works with one observability source. You can expand it later when you get access to the second tool.

If your team uses a different observability tool (Datadog, New Relic, Grafana Cloud), capture equivalent metrics: reliability targets, satisfaction scores, and active performance issues.

Your document is structured and grounded in real data. Next, you will build the mental model that connects any infrastructure decision to the customer experience it affects.

Build the Change-to-User Impact Chain

Your assessment kit document is set up and you have a real baseline from your team's Honeycomb and Sentry dashboards.

Now you need the core mental model that connects any infrastructure decision to what customers actually feel. The "Change-to-User Impact Chain" gives you a structured way to trace a technical change through four layers, ending at business risk.

In this step, get ready to:

Create a four-layer impact diagram for a cost-savings scenario.
Build a second chain for a reliability-focused database migration.
Document three Quick Assessment Questions that let you construct any chain fast.

Create the four-layer impact diagram

Every infrastructure change follows a chain reaction from what the platform team does, through system behavior, to what customers experience, to what leadership cares about. Your diagram captures this chain so you can trace any proposed change to its user-facing consequences.

In your Google Doc, scroll to the Change-to-User Impact Chain section heading.
Create a table or flowchart with four layers, labeled:
Fill in your first chain using a cost-savings scenario. Write 2-3 example signals for each layer:
Connect the layers with arrows or numbered flow to show the causal chain.

What is blast radius?

Blast radius refers to the scope of systems and users affected by a change.

In the EC2 downsize example, the blast radius includes every service running on those instances and every user journey that touches those services. The four-layer chain helps you trace from blast radius (Layer 2) all the way to business impact (Layer 4).

Build the database migration chain

Cost savings is one reason teams make infrastructure changes. Reliability improvements are another. A second chain shows how the same four-layer model works for a fundamentally different type of change.

Below your first chain, add a second four-layer chain for this reliability-focused scenario:
Connect the layers with arrows or numbered flow, matching the format of your first chain.

Why two different scenarios?

The cost-savings chain shows degradation that builds gradually (latency creep under load). The migration chain shows a concentrated risk window (brief but sharp disruption).

Practicing both patterns trains you to recognize that different change types produce different impact shapes, even though they flow through the same four layers.

Document the Quick Assessment Questions

Building a full chain for every change takes time. Three key questions let you construct any chain quickly by targeting the layers that matter most: system behavior, user experience, and business risk.

At the bottom of your Change-to-User Impact Chain section, add a subsection titled Quick Assessment Questions.
Write these three questions, each mapped to its corresponding layer:
Add a brief note explaining that answering these three questions in order gives you the skeleton of any impact chain in under two minutes.

Layer 1 is always given to you

Notice the questions start at Layer 2, not Layer 1. Layer 1 (the infrastructure decision) is what the platform team tells you they want to do.

Your job as the customer-facing person starts at Layer 2: understanding what that decision actually changes in the system.

Review your completed section to make sure both chains flow logically from Layer 1 through to Layer 4, and your Quick Assessment Questions are clearly labeled.

Not sure what to put in the layers?

If you are stuck on Layer 2 (system behavior), look at your Honeycomb baseline from Step 1. The SLOs your team has defined tell you which system behaviors are already being measured.

If Layer 3 (user experience) feels vague, think about specific user actions: logging in, loading a dashboard, submitting a form. Which of those would break or slow down if Layer 2 degraded?

Ask for help building your impact chains.

You now have a mental model that traces any infrastructure decision to business risk in four clear layers. Next up, you will turn this thinking into a structured template with scoring and communication decisions built in.

Create the Impact Assessment Template

Your Impact Chain gives you the mental model for connecting infrastructure decisions to business risk. Now you need a structured, repeatable template that turns that model into a checklist you can fill out for any proposed change.

In this step, you'll build a fill-in-the-blank assessment form with every question you should ask before a change ships. You'll also add a risk scoring system and a communication decision guide so you know exactly when to escalate.

In this step, get ready to:

Build a structured template with Change Summary, Blast Radius, NFR Impact, and Rollback Plan sections.
Add a Risk Scoring system with three dimensions and an escalation rule.
Create a Communication Decision guide with three severity tiers and examples.

Build the core template structure

The template needs to capture four categories of information about any proposed change. Each category surfaces a different type of risk that your Impact Chain taught you to trace.

In your Google Doc, scroll to the Impact Assessment Template heading you created in Step 1.
Create a table or structured form with four sections, each containing the fields described below.

Your four sections and their fields:

Change Summary: what is being changed, when is the change window, and who owns the change.
Blast Radius: which services are directly affected, which are downstream or transitive dependencies, and which user journeys touch those services.
NFR Impact: what happens to latency at p95, throughput capacity, error rates, and availability against the current SLO target.
Rollback Plan: how long does it take to roll back, is rollback automatic or manual, and what is the detection-to-rollback time window.

For each field, leave a blank space or placeholder text so you can fill it in quickly during a change review meeting.

What is blast radius?

Blast radius refers to the scope of systems and users affected by a change. It includes both direct dependencies (the service you're changing) and transitive dependencies (services that depend on the service you're changing).

A database migration might directly affect one service, but transitively affect every service that reads from that database. Mapping the full blast radius is what prevents surprises.

What are non-functional requirements?

Non-functional requirements (NFRs) describe how a system should perform, not what it does. They include latency (p50/p95/p99), throughput, error rates, and availability.

The key rule: convert adjectives to numbers. "Fast" is not an NFR. "p95 API latency under 250ms at 1,000 concurrent users" is.

Add the risk scoring system

A template alone does not tell you how urgent the risk is. You need a scoring system that converts your assessment into a clear signal: investigate, escalate, or proceed.

Below your template sections, add a new row or subsection titled Risk Scoring.
Add three dimensions, each with three levels:

Scope (how many users/services are affected):
Duration (how long the impact lasts):
Severity (how bad the degradation):

Below the three dimensions, add the escalation rule: any "High" on any dimension = escalate immediately.

Why these three dimensions?

Scope tells you how wide the impact is. Duration tells you how long users will feel it. Severity tells you how painful it is moment-to-moment.

A change that is High on scope but Momentary in duration (like a brief restart of a shared service) is a different conversation than one that is Low in scope but Persistent (like a degraded niche workflow that nobody notices for days).

Add the communication decision guide

Risk scoring tells you how serious the change is. The communication decision tells you what to do with that information. This is where your role as the bridge between platform engineering and customers becomes concrete.

At the bottom of your Impact Assessment Template, add a new subsection titled Communication Decision.
Add three tiers based on your risk score:

Low across all dimensions = no proactive communication needed, monitor signals.
Medium on any dimension = prepare internal talking points and alert CS/Support.
High on any dimension = proactive customer communication required, coordinate timing with the change window.

Write a one-sentence example for each level to make the tiers concrete. For instance:

Customize examples to your team

The examples above are generic starting points. Replace them with real scenarios from your team's recent changes. When the template references actual services and customers your colleagues recognize, adoption goes up dramatically.

Review your completed Impact Assessment Template section. You should now have a structured form with Change Summary, Blast Radius, NFR Impact, and Rollback Plan fields at the top. Below that, your Risk Scoring dimensions with the escalation rule. At the bottom, the Communication Decision guide with three tiers and examples.

Your template is ready to use in any change review meeting. Next up, you'll build the Observability Signal Map that tells you exactly which Honeycomb and Sentry metrics to watch after a change ships.

Map Observability Signals to Customer Language

Your Impact Assessment Template gives you a structured way to evaluate any proposed change. But once a change ships, you need to know what to watch and what it means for customers.

In this step, you will build an Observability Signal Map that translates metrics from Honeycomb and Sentry into customer-facing language. Each signal gets a plain-English explanation and a clear action threshold so you can respond quickly after any infrastructure change.

In this step, get ready to:

Document Honeycomb signals (SLO burn alerts, error budget status, BubbleUp anomalies) with customer-facing translations.
Document Sentry signals (User Misery, Apdex, Performance Issues) with customer-facing translations.
Create a Post-Change Monitoring Checklist with time-based checkpoints.

Document Honeycomb signals with customer language

Honeycomb's strength is its user-centric approach to reliability. Its SLOs are designed to measure close to the user, making them natural starting points for customer-impact translation.

In your Google Doc, scroll to your "Observability Signal Map" section heading.
Add a subheading called "Honeycomb".
Under that subheading, create three entries. Each entry should have the signal name, what it means in customer terms, and an action threshold.

Write these three entries:

SLO Burn Alerts: "When a burn alert fires, it means our error budget is depleting faster than expected. In customer terms: users are experiencing more failures or slowness than our reliability target allows. Action: investigate within 30 minutes."
Error Budget Status: "At 50% budget remaining with 50% of the month gone = on track. Below 30% remaining = customers are accumulating bad experiences. Action: flag to team, deprioritize risky changes."
BubbleUp Anomalies: "When BubbleUp highlights a dimension (e.g., a specific endpoint or user segment), it means that specific group is disproportionately affected. In customer terms: a subset of users or a specific workflow is degraded. Action: identify affected customer segment and assess communication need."

What are burn alerts and BubbleUp?

Honeycomb offers two types of SLO burn alerts: Exhaustion Time (triggers if extrapolated budget exhaustion falls within a specified window) and Budget Rate (triggers if budget decreases by a configured percentage over a time window). Both tell you the same thing in customer terms: reliability is degrading faster than planned.

BubbleUp computes a baseline for all dimensions within and outside a selected time range, then surfaces the dimensions that differ the most. This is how you pinpoint which specific user segment or workflow is disproportionately affected.

Customize the action thresholds

The "investigate within 30 minutes" and "below 30% remaining" thresholds are starting points. Adjust them based on your team's SLO targets and on-call response capacity.

Document Sentry signals with customer language

Sentry provides metrics specifically designed to quantify how many real humans are having a bad experience. These are your strongest signals for determining whether an infrastructure change has crossed the line from "internal metric moved" to "customers are frustrated."

Below your Honeycomb section, add a subheading called "Sentry".
Create three entries following the same format: signal name, customer-facing meaning, and action threshold.

Write these three entries:

User Misery: "This counts unique users experiencing load times 4x the satisfactory threshold. Rising User Misery after a deploy = real humans are frustrated. Action: correlate with the change, assess rollback."
Apdex Score: "Ranges 0-1. Above 0.9 = most users satisfied. Between 0.7-0.9 = tolerable but degraded. Below 0.7 = users are frustrated. Action threshold: if Apdex drops more than 0.05 after a change, investigate."
Performance Issues (N+1 queries, slow DB queries): "Sentry auto-detects these. In customer terms: specific actions in the app are noticeably slower. Action: check if the new issue correlates with a recent infrastructure change."

What is User Misery?

User Misery is a Sentry metric that counts unique users who experienced load times 4x your project's configured satisfactory threshold. It uses a probability distribution to avoid false positives at low traffic volumes.

Apdex is an industry-standard satisfaction score ranging from 0 to 1.0, where 1.0 means 100% of users had a satisfactory experience. The 0.05 drop threshold is a practical starting point. A drop larger than that after a change suggests real user impact.

What does Sentry auto-detect?

Sentry automatically detects performance issues including N+1 queries, consecutive DB queries that could be batched, database and file I/O on the main thread, endpoint regressions, function regressions, and slow DB queries. These detections surface without you needing to configure manual thresholds.

Create a Post-Change Monitoring Checklist

Individual signals are useful, but after a change ships you need a time-sequenced plan. This checklist tells you exactly when to check each tool and what to look for at each interval.

Below both your Honeycomb and Sentry sections, add a subheading called "Post-Change Monitoring Checklist".
Write the following time-based checkpoints:

Within 15 minutes: Check Sentry for new performance issues or error spikes. These surface fastest because Sentry detects them automatically at deploy time.
Within 1 hour: Check Honeycomb SLO burn rate for acceleration. Burn alerts need enough data points to trigger, so give them time to accumulate.
Within 24 hours: Compare Sentry Apdex and User Misery against your pre-change baseline. These metrics need a full traffic cycle to show meaningful trends.

Add a final line linking back to your template: "If any signal crosses its action threshold, trigger the Communication Decision from the Impact Assessment Template."

Why these specific time intervals?

The 15-minute, 1-hour, and 24-hour intervals match how quickly each tool surfaces meaningful data. Sentry detects performance regressions almost immediately. Honeycomb burn alerts need enough events to calculate a reliable rate. Apdex and User Misery need a representative traffic sample to avoid reacting to noise.

This sequenced approach prevents both false alarms (checking too early) and missed impact (checking too late).

Your Observability Signal Map is complete. You now have a reference that translates raw metrics into customer-facing language with clear action triggers. Next up, you will put the entire framework to the test by running a realistic scenario through it end to end.

Run a Worked Example

Your Observability Signal Map now translates raw metrics into customer language. You have the vocabulary to explain what a burn alert or an Apdex drop means for real users.

Now it is time to stress-test the entire framework end-to-end. You will run a realistic infrastructure scenario through every section of your kit to see how the pieces connect and to practice the full assessment flow before you need it in a real meeting.

In this step, get ready to:

Fill in the Impact Assessment Template for a database migration scenario.
Score the risk and draft the communication decision.
Map the post-change monitoring plan with concrete "all clear" criteria.

Fill in the Impact Assessment Template for the migration scenario

A worked example makes the framework concrete. You will assess a common, high-stakes change that platform teams propose: migrating from a self-managed PostgreSQL instance to Amazon Aurora PostgreSQL.

Navigate to your "Worked Example" section in your Google Doc.
Write the scenario description at the top of the section:
"The platform team proposes migrating from a self-managed PostgreSQL instance to Amazon Aurora PostgreSQL. The migration requires a maintenance window with a brief cutover period. It is expected to improve long-term reliability and reduce ops burden."
Fill in the Change Summary row: what (database engine migration), when (scheduled maintenance window), who owns it (platform/infra team).
Fill in the Blast Radius row: all services using the primary database, all read replicas, and all user journeys that involve writes.
Fill in the NFR Impact row: brief latency spike during cutover, potential connection pool exhaustion if apps do not handle reconnection gracefully, and long-term improvement to availability.
Fill in the Rollback Plan row: point-in-time recovery is available, but rollback to the original instance takes 30-60 minutes.

Why this scenario?

Database migrations touch nearly every service in a typical stack. This makes the blast radius wide and the risk assessment non-trivial.

The scenario also involves a maintenance window, which forces you to think about timing, communication, and rollback. These are the exact pressures you will face in a real change review.

Score the risk and draft the communication decision

With the template filled in, you can now apply your risk scoring dimensions to determine how urgently this change needs escalation.

Below your completed template rows, add a Risk Score heading.
Score the Scope dimension: High. All services use the database, so multiple critical user journeys are affected.
Score the Duration dimension: Window. The maintenance window lasts 15-60 minutes.
Score the Severity dimension: Impaired. A subset of users will see errors during cutover, but the system does not go fully down.
Write the conclusion: any "High" dimension triggers immediate escalation.

What does High/Window/Impaired mean in practice?

This combination tells you the change is wide-reaching (every user journey that writes data), time-bounded (not permanent), and partially degrading (not a total outage). The "High" on Scope alone is enough to trigger your escalation path.

Below the risk score, add a Communication Decision heading.
Note that because risk is High on Scope, proactive customer communication is required.
Draft a 3-sentence internal brief:
"We are migrating our primary database on [date] during a maintenance window. Users may experience brief errors or slowness (up to 60 seconds) during the cutover. Long-term, this improves reliability and reduces incident risk."
Add a recommendation line: "Recommended: schedule during lowest-traffic window, notify affected enterprise customers 48 hours in advance."

Keep the brief jargon-free

Notice the internal brief says "errors or slowness" instead of "connection pool exhaustion" or "latency spike." This is your translation layer in action. When you share this with CS or Support, they can pass it directly to customers without needing to decode infrastructure language.

Map the monitoring plan with "all clear" criteria

The final piece is knowing what to watch after the change ships and when you can confidently say the migration succeeded.

Below the communication brief, add a Monitoring Plan heading.
Under a Honeycomb subheading, list the signals to watch: SLO burn rate for the edge service, and error budget consumption during and after the maintenance window.
Under a Sentry subheading, list the signals to watch: new performance issues flagged within 1 hour, Apdex score comparison pre/post, and User Misery count.
Add an "All Clear" Criteria subheading with these thresholds:
SLO burn rate returns to baseline within 2 hours.
No new Sentry performance issues after 4 hours.
Apdex within 0.02 of pre-change baseline within 24 hours.

Why define "all clear" criteria upfront?

Without pre-defined criteria, teams tend to declare victory too early or keep watching indefinitely. By committing to specific thresholds before the change, you remove ambiguity from the post-change conversation.

If any signal crosses its action threshold before hitting "all clear," you trigger the Communication Decision from your template. The framework loops back on itself.

Your framework is complete. You now have a reusable kit that takes any infrastructure change from proposal to monitored outcome. Next up, the Secret Mission challenges you to apply this to a real change on your team's roadmap.

Secret mission

Assess a Real Upcoming Change

You have practiced the framework on a hypothetical database migration. Now take a real infrastructure change from your team's current or upcoming roadmap and run it through your complete kit. Real changes come with ambiguity, undocumented dependencies, and judgment calls that no worked example can replicate.

Clean Up Your Resources

This project runs entirely locally using Google Docs and your existing observability access. There are no ongoing costs or cloud resources to manage.

Resources you created:

Infrastructure Change Impact Assessment Kit (Google Doc).

Your Honeycomb and Sentry dashboard access is unchanged from before the project. No new accounts, integrations, or configurations were created.

Keep everything running

No action needed. Choose this if you plan to use the framework in upcoming sprint planning or change review meetings.

Your Impact Assessment Kit document stays in Google Drive, ready to use.
Update the Observability Signal Map as your team adds new SLOs or changes monitoring tools.
After using the template 3-5 times, revisit and refine. Add common scenarios your team encounters and adjust risk thresholds based on what you learn about your system's actual sensitivity.

Pause - I'll come back to this later

Archive the document to keep your Drive tidy while preserving it for later.

Open Google Drive and locate your Infrastructure Change Impact Assessment Kit document.
Right-click the document and select Organize, then move it to a folder like Archived Projects.
The document remains accessible whenever you need it, just out of your main workspace.

Delete - I don't want to use this again

Remove the project document entirely.

Open Google Drive and locate your Infrastructure Change Impact Assessment Kit document.
Right-click the document and select Move to trash.
To permanently delete, click Trash in the left sidebar, then right-click the document and select Delete forever.

Nice Work!

You just built a complete Infrastructure Change Impact Assessment Kit. You now have the vocabulary, mental models, and signal awareness to detect when a proposed infrastructure change could affect users, and the templates to communicate that risk clearly.

Here's what you accomplished:

Built a four-layer Change-to-User Impact Chain mental model that maps any infrastructure decision through system behavior, user experience, and business risk.
Created a structured Impact Assessment Template with blast radius analysis, NFR impact scoring, rollback planning, and communication decision criteria.
Translated Honeycomb SLO burn alerts and Sentry User Misery/Apdex metrics into customer-facing language with clear action thresholds and a post-change monitoring checklist.
Secret Mission: Applied the complete framework to a real upcoming change on your team's roadmap and received feedback from your platform team lead.

Ready to quiz yourself?