Go-Live & Incident Response Guideline
Department
Table of Contents
Purpose
This guideline defines the minimum operational playbook for go-live execution and incident response (who does what, what to write in Asana, and what “done” means).
| Outcome |
|---|
| Production changes are executed with clear ownership, and incidents are handled with fast containment and clear communication. |
Scope
This guideline covers:
| Included | |
|---|---|
| 1 | Environment definitions and promotion flow |
| 2 | Go-live execution responsibilities (including rollback) |
| 3 | Minimum incident response workflow and artifacts |
This guideline does not replace project-specific deployment runbooks. If a project needs a custom runbook, it should be linked from the go-live Asana task.
Definitions
| Term | Definition |
|---|---|
| Go-live | Release a change into Production (real users / real operations) |
| Rollback | Reverting to a known-safe state when go-live introduces unacceptable risk or failure |
| Incident | A production issue that materially impacts user experience, data correctness, or business operations |
Operating Model (Sprint + Asana + Visibility)
| Operating Model | |
|---|---|
| 1 | Asana is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
Environment Overview
| Environment | Description |
|---|---|
| Local | Developer machine for coding and testing |
| DEV | Internal team testing server |
| UAT / DEMO | Client-facing trial environment for validating that functions work correctly per agreement and are acceptable |
| Staging | Pre-production environment that is as close to Production as possible for final testing |
| Production | Live system for real users |
Workflow Summary
Development → Testing → Client validation → Production-like validation → Go live
Local → DEV → UAT/DEMO → Staging → Production
Step-by-Step Process
| Step | |
|---|---|
| 1 | Confirm go-live owner + execution window (who runs the change, when, who is on standby) |
| 2 | Confirm rollback plan exists (what rollback means here + how to execute it) |
| 3 | Confirm verification plan exists (the checklist that declares success) |
| 4 | Execute go-live and record execution notes in Asana |
| 5 | Verify, then communicate outcome (success / rollback / follow-up actions) |
Decision point: go-live outcome
| Outcome | Action |
|---|---|
| Verified (success) | Proceed to hypercare/monitoring plan (if defined) and close the go-live execution task. |
| Not verified (failure / unacceptable risk) | Execute rollback plan, record what happened, and align next steps + new schedule. |
Asana Card Template: Go-live execution (Technology)
| Asana Card Template | |
|---|---|
| Title | Go-live execution (Technology) – [Client Name] – [Project Title] |
| Assignee | Technology owner |
| Description | Please execute go-live for this project. References • Project card: [Link] • Delivery go-live task: [Link] Environment path Local → DEV → UAT/DEMO → Staging → Production Rollback plan • Rollback approach (high-level): [Notes/link] Verification plan • What to verify post-release: [Checklist/link] Execution • Go-live datetime: [Datetime] • Execution notes (minimum): what changed + start time + end time + any deviations + who executed Result • Outcome: Verified / Rolled back • Follow-ups (if any): [List/link] |
Incident Response (Minimum)
| Step | |
|---|---|
| 1 | Triage and confirm impact (what is broken, who is affected, severity) |
| 2 | Contain (stop the bleeding: rollback, disable feature, hotfix, mitigation) |
| 3 | Communicate status (AE/PM aligned; client comms when needed) |
| 4 | Resolve and verify |
| 5 | Record a short incident summary and follow-up tasks (prevent recurrence) |
Asana Card Template: Incident
| Asana Card Template | |
|---|---|
| Title | Incident – [System/Feature] – [Short description] |
| Assignee | Technology owner |
| Description | Impact: [Who is affected / what is broken] Severity: [Low/Medium/High] Start time: [Datetime] Containment: [Actions taken] Current status: [Short] Client comms owner (AE/PM): [Name] Resolution: [What fixed it] Verification: [What checks passed] Follow-ups: [Tasks/links] |
Go-Live Checklist (Technology Use)
Preconditions
| Checklist | |
|---|---|
| 1 | ☐ Go-live owner assigned |
| 2 | ☐ Rollback plan exists (high-level) |
| 3 | ☐ Verification plan exists |
| 4 | ☐ Relevant stakeholders are on standby (as agreed) |
Execution
| Checklist | |
|---|---|
| 1 | ☐ Execution notes recorded in Asana |
| 2 | ☐ Verification completed |
| 3 | ☐ Outcome communicated (success / rollback / next steps) |