JustAnalytics/Documentation

Incidents

Manage incidents on your status page with status workflows and subscriber notifications.

Overview#

Incidents are the primary way to communicate service disruptions to your users via the status page. Each incident follows a structured workflow from detection to resolution, with updates that automatically notify subscribers.

Creating an Incident#

From the Dashboard#

  1. Navigate to Monitoring > Status Pages and select your status page
  2. Click Create Incident
  3. Fill in the incident details:

| Field | Description | Required | |-------|-------------|----------| | Title | Short description of the issue | Yes | | Status | Current investigation status | Yes | | Impact | Severity level | Yes | | Affected Monitors | Which services are impacted | Yes | | Message | Detailed update for subscribers | Yes |

From the API#

Create incidents programmatically (e.g., from your alerting pipeline):

POST /api/status-pages/{slug}/incidents
X-API-Key: ja_sk_...
Content-Type: application/json

{
  "title": "Elevated API error rates",
  "status": "investigating",
  "impact": "minor",
  "affectedMonitors": ["api", "webhooks"],
  "message": "We are investigating increased error rates on the API. Some requests may fail intermittently."
}

Auto-Created Incidents#

When an uptime monitor linked to a status page goes down, JustAnalytics can automatically create an incident:

  1. Go to status page settings and enable Auto-Incident Creation
  2. Configure the delay (default: 2 consecutive failures before creating an incident)
  3. Auto-created incidents have status "investigating" and impact "minor" by default
  4. They are automatically resolved when the monitor recovers

Status Workflow#

Every incident progresses through a defined status workflow:

Investigating#

The initial status. Your team is aware of the issue and actively looking into it.

  • When to use: Issue detected, root cause unknown
  • Subscriber notification: "We are investigating reports of..."
  • Monitor display: Affected monitors show a yellow/orange indicator

Identified#

The root cause has been found and a fix is being implemented.

  • When to use: Root cause known, working on a fix
  • Subscriber notification: "The issue has been identified. We are implementing a fix..."
  • Monitor display: Affected monitors remain in degraded/outage state

Monitoring#

A fix has been deployed and the team is verifying it works.

  • When to use: Fix deployed, watching for stability
  • Subscriber notification: "A fix has been implemented. We are monitoring..."
  • Monitor display: Monitors may show recovery

Resolved#

The incident is over and service has been fully restored.

  • When to use: Service confirmed stable
  • Subscriber notification: "This incident has been resolved..."
  • Monitor display: Monitors return to operational status
  • Post-resolution: Incident moves to the history section

Impact Levels#

Impact levels determine the visual severity on the status page and influence notification urgency.

| Impact | Description | Status Page Display | |--------|-------------|---------------------| | None | Informational, no user impact | Gray banner, no monitor changes | | Minor | Some users may experience issues | Yellow indicator on affected monitors | | Major | Significant functionality impaired | Orange indicator, prominent banner | | Critical | Service completely unavailable | Red indicator, full-width alert banner |

Overall Status Calculation#

The status page's overall status is the worst active incident impact:

  • No active incidents = All Systems Operational (green)
  • Minor impact = Minor Service Disruption (yellow)
  • Major impact = Partial System Outage (orange)
  • Critical impact = Major System Outage (red)

Posting Updates#

Keep subscribers informed by posting updates throughout the incident lifecycle.

Adding an Update#

  1. Open the active incident
  2. Click Post Update
  3. Select the new status (or keep the current one)
  4. Write a message explaining the latest developments
  5. Click Publish -- subscribers are notified immediately

Update Best Practices#

  • Be specific: "Database replica lag causing read timeouts on the /users endpoint" is better than "experiencing issues"
  • Include timelines: "We expect a fix within 30 minutes" helps users plan
  • Update every 30 minutes during active incidents, even if there is no new information
  • Final update: Summarize root cause, what was fixed, and any follow-up actions

Update Notification Channels#

Each update triggers notifications to:

  • Email subscribers -- formatted HTML email with incident details
  • RSS feed -- new entry appended to the feed
  • Webhook subscribers -- POST with incident payload
  • In-app -- notification bell for dashboard users

Maintenance Window Scheduling#

Planned maintenance is a special type of incident that is scheduled in advance.

Creating a Maintenance Window#

  1. Navigate to your status page and click Schedule Maintenance
  2. Configure:

| Field | Description | |-------|-------------| | Title | What is being maintained | | Description | Detailed explanation of the work | | Start Time | When maintenance begins (with timezone) | | End Time | Expected completion time | | Affected Monitors | Services that will be impacted | | Auto-Start | Automatically mark monitors as "Under Maintenance" at start time | | Auto-End | Automatically resolve the maintenance at end time |

Maintenance Lifecycle#

  1. Scheduled -- appears on the status page as "Upcoming Maintenance" with countdown
  2. In Progress -- at start time, affected monitors show "Under Maintenance" (blue indicator) instead of "Down"
  3. Completed -- at end time or when manually resolved, monitors return to normal status

Subscriber Notifications for Maintenance#

Subscribers receive notifications at these points:

  • When scheduled -- advance notice (e.g., "Scheduled maintenance on March 15 from 2:00 AM to 4:00 AM UTC")
  • 24 hours before -- reminder notification
  • When started -- "Maintenance has begun"
  • When completed -- "Maintenance is complete, all services are operational"

Incident History#

The status page displays a chronological history of past incidents:

  • Last 90 days of incident history displayed by default
  • Each day shows incidents with their final status and duration
  • Days with no incidents show "No incidents reported"
  • Full incident timeline (all updates) visible on click
  • Searchable and filterable by date range

Incident Templates#

Create reusable templates for common incident types:

  1. Go to Status Page Settings > Templates
  2. Create templates with pre-filled title, impact, affected monitors, and initial message
  3. When creating a new incident, select "Use Template" to pre-populate fields

Example templates:

  • "Database Maintenance" -- minor impact, database monitors, standard maintenance message
  • "CDN Issues" -- major impact, all monitors, investigation message
  • "Deployment" -- none impact, API monitors, rolling deployment message