Skip to main content

Overview

Incident updates allow you to add progress reports to ongoing incidents, keeping users informed as you work toward resolution.

Adding an Update

To add an update to an existing incident:
  1. Navigate to your Status Page
  2. Click Incidents
  3. Select the active incident
  4. Click Add Update or similar button

Update Fields

Status (select from dropdown):
  • Investigating
  • Identified
  • Monitoring
  • Resolved
Message:
  • Clear, concise update on current situation
  • What you’ve discovered or fixed
  • What you’re doing next
  • Estimated resolution time (if known)
Affected Components (optional):
  • Update which services are impacted
  • Can change as incident evolves

Update Timeline

All updates appear in chronological order on your status page, showing:
  • Timestamp of each update
  • Status at that time
  • Update message
  • Who posted it (internal only)

Update Frequency Guidelines

Critical Incidents

  • First 15 minutes: Every 5-10 minutes
  • Next 30 minutes: Every 15 minutes
  • After 1 hour: Every 30 minutes
  • Even without progress: Update to show you’re working on it

Major Incidents

  • First 30 minutes: Every 15 minutes
  • After 30 minutes: Every 30-60 minutes

Minor Incidents

  • First hour: Every 30 minutes
  • After resolution: Final update with summary
Long periods without updates make users assume you’re not working on the issue. Update regularly even if there’s no new information.

Update Examples

Investigating Update

Status: Investigating
Time: 2:05 PM

We're seeing elevated error rates on the API (approximately 5% of requests).
Our team is investigating the root cause. We'll provide another update
within 15 minutes.

Identified Update

Status: Identified
Time: 2:18 PM

We've identified the issue as a misconfiguration in our load balancer
introduced during today's deployment. We're rolling back the deployment
and expect services to stabilize within 10 minutes.

Monitoring Update

Status: Monitoring
Time: 2:35 PM

The deployment has been rolled back and error rates have returned to normal.
We're monitoring closely for the next 30 minutes to ensure stability before
marking this incident as resolved.

Resolved Update

Status: Resolved
Time: 3:10 PM

All systems are operating normally. Error rates have been at baseline levels
for the past 30 minutes. The deployment issue has been resolved and we've
added additional validation to prevent similar issues in the future.
Thank you for your patience.

Best Practices

Don’t say “working on it” - say “rolling back deployment” or “restarting database servers”.
If you can estimate resolution time, include it. If not, say when you’ll provide the next update.
Help users understand who is affected and what functionality is impaired.
Avoid internal terminology. Write for your users, not your team.
Show empathy. “We understand this is frustrating” goes a long way.
“No update yet, still investigating” is better than silence.

Status Progression

Typical incident progression:
Investigating → Identified → Monitoring → Resolved
But you can skip steps if appropriate:
Investigating → Resolved (for quick fixes)
Investigating → Monitoring → Resolved (if cause is unclear)

What NOT to Include

  • Internal team member names
  • Internal ticket/bug IDs
  • Blame or finger-pointing
  • Sensitive technical details
  • Excessive technical jargon
  • Promises you can’t keep

Notification Behavior

When you add an incident update:
  • Status page is updated immediately
  • Subscribers receive notifications (if configured)
  • Slack/Teams channels receive posts
  • RSS feed is updated
  • Status badge reflects current state
Subscribers only get notified when you change the incident status, not for every update. This prevents notification fatigue.

Editing Past Updates

Some platforms allow editing previous updates:
  • Fix typos or unclear language
  • Add missing information
  • Clarify technical details
However, avoid:
  • Deleting updates to hide mistakes
  • Changing the meaning of past updates
  • Removing timestamps or chronology

Templates for Common Scenarios

Database Issues

Investigating: We're experiencing database connection issues affecting
[service]. Users may see errors when [action]. Investigating now.

Identified: Issue traced to [specific cause]. Implementing [solution].
ETA: [timeframe].

Resolved: Database connectivity restored. All services operating normally.

API Slowdowns

Investigating: API response times are slower than normal (500ms vs usual 100ms).
Checking server load and database queries.

Monitoring: Implemented query optimization. Response times improving
(now 150ms average). Monitoring for stability.

Resolved: API performance back to normal levels. Average response time: 95ms.

Deployment Rollback

Investigating: Recent deployment causing errors in [feature]. Rolling back now.

Monitoring: Rollback complete. Error rates decreasing. Watching metrics.

Resolved: All systems stable. Deployment has been rolled back.
Issue will be fixed before next deployment.

Next Steps