What This Template Is For
An internal change log is a chronological record of every meaningful change to your product. It is different from external release notes (which are written for customers) and different from a git commit history (which is written for developers). An internal change log is written for the entire company: product, engineering, design, sales, support, marketing, and leadership.
When a customer calls support and says "something changed in my dashboard," the support agent needs to quickly find what shipped and when. When a sales rep is on a call and the prospect asks about a feature that was just released, the rep needs to know it exists. When the CEO asks "what did we ship last quarter?", the PM needs a clean answer that does not require digging through Jira tickets.
This template provides a structured format for logging changes that includes the information every team needs: what changed, when, who is affected, what the impact is, whether it can be rolled back, and who to contact. For external-facing release communication, see the release notes template. For planning the release itself, the release planning template covers the coordination process.
When to Use This Template
- After every production deployment that changes user-facing behavior. This includes new features, feature changes, removed features, UX changes, pricing changes, and significant performance improvements.
- After infrastructure changes that affect product behavior. Database migrations, API versioning, CDN changes, and third-party integration updates belong in the log even if users do not directly see them. Support and engineering need to know.
- When rolling out feature flags or gradual rollouts. Log the start of a rollout, each expansion (10% to 50% to 100%), and the final full release as separate entries. This creates an audit trail for gradual deployments.
- When reverting or rolling back a change. The rollback itself is a change that needs to be logged, including why the original change was reverted.
- For configuration changes that affect product behavior. Changing a rate limit, adjusting a default setting, or modifying a pricing threshold are changes that affect the user experience even though no code was deployed.
How to Use This Template
- Create one entry per logical change, not per deployment. If a single deployment includes a new search feature and a bug fix for the billing page, log them as two separate entries. Each change should be independently searchable.
- Fill in the entry within 24 hours of the change going live. Logging changes a week later defeats the purpose. Support needs the information immediately.
- Use the impact assessment to flag high-risk changes. Not every change needs the same level of attention. A color tweak to a button is low-impact. A change to how invoices are calculated is high-impact. The assessment helps teams triage their attention.
- Notify affected teams proactively. Do not rely on people reading the log. For medium and high-impact changes, send a direct notification to the teams listed in the "Teams to Notify" field.
- Review the log monthly. At the end of each month, scan the log for patterns. Are you shipping too many changes at once? Are certain types of changes causing more incidents? The log is both a communication tool and a process improvement tool.
The Template
Change Log Entry
Change ID. [CL-YYYY-NNN, e.g., CL-2026-047]
Date. [YYYY-MM-DD]
Time (UTC). [HH:MM]
Change Title. [Short, descriptive title. "Updated dashboard chart rendering" not "Sprint 47 release"]
Change Type. [New Feature / Feature Change / Bug Fix / Removal / Infrastructure / Configuration / Rollback]
Severity. [Low / Medium / High / Critical]
Description.
[2-3 sentences explaining what changed and why. Write for a non-technical audience. "The search bar now shows results as you type instead of requiring you to press Enter" is better than "Implemented debounced autocomplete with 300ms delay on the search input component."]
User Impact.
[Who is affected and how? Be specific. "All users on the Pro plan will see a new 'Export to CSV' button on the Reports page" is better than "Reports updated."]
Affected Areas.
[List the specific pages, features, APIs, or integrations affected. e.g., "Dashboard > Charts tab, /api/v2/charts endpoint, Zapier chart trigger"]
Rollout Strategy.
| Aspect | Detail |
|---|---|
| Rollout type | [Full release / Feature flag / Percentage rollout / Opt-in] |
| Current rollout % | [100% / 50% / 10% / etc.] |
| Target full rollout date | [YYYY-MM-DD] |
| Rollback available? | [Yes / No] |
| Rollback procedure | [Brief description or link to runbook] |
| Rollback decision owner | [Name, Role] |
Teams to Notify.
| Team | Why | Notification Sent? |
|---|---|---|
| Support | [They will receive questions about this change] | [Yes/No] |
| Sales | [This affects demos or pricing conversations] | [Yes/No] |
| Marketing | [This affects messaging or documentation] | [Yes/No] |
| Customer Success | [This affects onboarding or account health] | [Yes/No] |
| Engineering (other teams) | [This affects their APIs or integrations] | [Yes/No] |
Related Items.
| Item | Link |
|---|---|
| Jira / Linear ticket | [URL] |
| PRD or spec | [URL] |
| Design file | [URL] |
| External release notes | [URL or "Not applicable"] |
| Monitoring dashboard | [URL] |
Owner. [Name, Role]
Reviewed By. [Name, Role]
Monthly Change Summary Table
Use this table as a running index for the month. Each row links to a detailed entry above.
| Change ID | Date | Title | Type | Severity | Rollout | Owner |
|---|---|---|---|---|---|---|
| CL-2026-047 | 2026-03-05 | |||||
| CL-2026-048 | ||||||
| CL-2026-049 | ||||||
| CL-2026-050 | ||||||
| CL-2026-051 |
Quarterly Statistics
Track these metrics at the end of each quarter to spot trends.
| Metric | Q_ Value | Previous Q | Change |
|---|---|---|---|
| Total changes logged | |||
| New features | |||
| Bug fixes | |||
| Rollbacks | |||
| High/Critical severity changes | |||
| Average changes per week | |||
| Changes requiring rollback |
Filled Example: B2B Analytics Platform
Context. A product team at a mid-market analytics SaaS logs changes to their internal change log. Below are three representative entries from a single week, showing the range of change types and severity levels.
Entry 1: New Feature
Change ID. CL-2026-038
Date. 2026-02-24
Time (UTC). 14:30
Change Title. Added scheduled report delivery via email
Change Type. New Feature
Severity. Medium
Description. Users can now schedule any saved report to be delivered to a list of email addresses on a daily, weekly, or monthly cadence. Reports are generated as PDF attachments. This was the second most requested feature in our Q4 customer survey.
User Impact. All users on Pro and Enterprise plans can access this feature via the Reports page. Free plan users will see the option but will be prompted to upgrade. Approximately 2,400 active Pro/Enterprise accounts are eligible.
Affected Areas. Reports page (new "Schedule" button), Settings > Notifications (new delivery preferences), /api/v2/reports/schedule endpoint (new), Email delivery system (new scheduled job).
Rollout Strategy. Feature flag, currently at 25% of Pro/Enterprise accounts. Full rollout planned for 2026-03-03 if no issues. Rollback available by disabling the feature flag. Rollback owner: Sarah (Engineering Lead).
Teams to Notify. Support (Yes, sent FAQ doc), Sales (Yes, added to demo script), Marketing (Yes, blog post scheduled for full rollout), Customer Success (Yes, included in weekly CS digest).
Entry 2: Bug Fix
Change ID. CL-2026-039
Date. 2026-02-25
Time (UTC). 09:15
Change Title. Fixed incorrect date range in exported CSV files
Change Type. Bug Fix
Severity. High
Description. CSV exports from the dashboard were including data from outside the selected date range. If a user selected "Last 7 days," the export included data from the last 14 days. The issue was introduced in CL-2026-031 (dashboard refactor, 2026-02-10) and affected all users who exported CSV files since that date.
User Impact. All users who exported CSV data between 2026-02-10 and 2026-02-25 received incorrect files. Approximately 340 exports were affected. Customer Success is reaching out to the 50 most active exporters to notify them and offer re-exports.
Affected Areas. Dashboard > Export CSV, /api/v2/export endpoint.
Rollout Strategy. Full release, no feature flag. Rollback not applicable (this is a fix). The bug was caused by an off-by-one error in the date filter query.
Entry 3: Rollback
Change ID. CL-2026-040
Date. 2026-02-26
Time (UTC). 16:45
Change Title. Rolled back new chart rendering engine (CL-2026-037)
Change Type. Rollback
Severity. Critical
Description. The new chart rendering engine (shipped 2026-02-23) caused a 400% increase in page load time for dashboards with more than 10 charts. The issue was not caught in QA because test dashboards had a maximum of 5 charts. The rollback restores the previous rendering engine while the performance issue is investigated.
User Impact. Enterprise users with large dashboards experienced 8-12 second load times (vs. normal 2-3 seconds) for 3 days. 23 support tickets were filed. After rollback, load times returned to normal within 15 minutes.
Key Takeaways
- Write for the support agent, not the developer. The internal change log should be understandable by anyone in the company. Technical details belong in the ticket or PR description. The change log entry should explain what changed in plain language.
- Log every change, even small ones. The time you think "this is too minor to log" is exactly when support will get a ticket about it. Five minutes of logging prevents an hour of investigation. For managing larger release cycles, see the Product Operations Handbook.
- Track rollbacks and their root causes. A high rollback rate signals problems in your testing or release process. If you are rolling back more than 5% of changes, investigate whether the issue is scope, QA coverage, or deployment frequency.
- Use the "Teams to Notify" field actively. The change log is a reference document. Notifications are proactive communication. For high and medium-severity changes, do not wait for people to check the log. Send the notification before the change goes live when possible.
- Review quarterly statistics as a team. The data reveals process health. Rising bug fix counts may indicate quality issues. Rising rollback counts may indicate rushed releases. Use the sprint retrospective template to discuss these patterns with the team.
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use