Squadcast On-Call Management: SRE Workflows for QA and DevOps Teams

Squadcast is an incident management and on-call platform built specifically for SRE and DevOps teams. While tools like PagerDuty and OpsGenie target the broad enterprise market, Squadcast positions itself as the SRE-native alternative — tighter on core incident workflows, more opinionated on best practices, and significantly more affordable.

For QA teams working alongside SREs, Squadcast offers a clean way to integrate test failure alerting into the same system your infrastructure team uses for reliability incidents. One platform, unified incident history, shared on-call rotations.

Squadcast's Core Model

Squadcast organizes incident management around a few key concepts:

Services — Logical units you want to monitor. A "service" might be your payment API, your frontend, or your CI test suite. Each service has its own alert routing configuration.

Escalation Policies — Rules for how alerts route through your team. Who gets paged first, who gets escalated to, and when.

Schedules — On-call rotation calendars. Who's on duty, when, and for which services.

Squads — Groups of users. Squads can be assigned to escalation policies to route by team rather than individual.

Incidents — The central lifecycle object. Incidents track who responded, what actions were taken, and when the issue resolved.

Runbooks — Documentation linked to services. When an incident fires, responders see the relevant runbook automatically.

Setting Up a QA Service

Create a dedicated Squadcast service for your QA testing infrastructure:

1. Go to Services → Add Service
2. Name it "QA Test Suite" or "CI Pipeline"
3. Assign it to your QA team (Squad)
4. Set an escalation policy (create this first, see below)
5. Configure alert source integrations

Once the service is created, Squadcast generates an inbound webhook URL you'll use to connect your CI system.

Escalation Policy for QA Tests

Before creating the service, define how alert escalation should work for test failures:

1. Go to Escalation Policies → Create Policy
2. Layer 1: Notify on-call engineer (immediately)
3. Layer 2: Notify squad lead if no ack in 10 minutes
4. Layer 3: Notify engineering manager if no ack in 25 minutes

Set different policies for different severity levels:

• Production test failures — Immediate page, aggressive escalation
• Staging test failures — 15-minute delay before first page, no after-hours escalation
• Non-critical tests — Business hours notification only

Connecting CI/CD to Squadcast

Webhook Integration

Squadcast supports inbound webhooks directly. Send a POST request to your service webhook URL:

curl -X POST "https://api.squadcast.com/v1/incidents/api/{{ YOUR_WEBHOOK_TOKEN }}" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "CI Test Suite Failed",
    "description": "Test suite failed on main branch. 12 tests failed out of 247.",
    "status": "trigger",
    "tags": {
      "environment": {
        "value": "staging",
        "color": "#ffa500"
      },
      "type": {
        "value": "test-failure",
        "color": "#ff0000"
      }
    }
  }'

The tags field is useful — Squadcast displays these tags in the incident view, giving responders immediate context about the environment and failure type.

GitHub Actions Integration

name: Test and Alert

on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run tests
        id: test_run
        run: npm test 2>&1 | tee test-results.txt
        continue-on-error: true
      
      - name: Alert Squadcast on failure
        if: steps.test_run.outcome == 'failure'
        run: |
          FAILED_COUNT=$(grep -c "FAIL " test-results.txt || echo "unknown")
          curl -X POST "${{ secrets.SQUADCAST_WEBHOOK_URL }}" \
            -H "Content-Type: application/json" \
            -d "{
              \"message\": \"Test failure: ${{ github.repository }} ($FAILED_COUNT tests failed)\",
              \"description\": \"Branch: ${{ github.ref_name }}\nCommit: ${{ github.sha }}\nTriggered by: ${{ github.actor }}\nCI Run: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}\",
              \"status\": \"trigger\",
              \"tags\": {
                \"environment\": {\"value\": \"staging\", \"color\": \"#ffa500\"},
                \"severity\": {\"value\": \"high\", \"color\": \"#ff0000\"}
              }
            }"
      
      - name: Resolve Squadcast incident on success
        if: steps.test_run.outcome == 'success'
        run: |
          curl -X POST "${{ secrets.SQUADCAST_WEBHOOK_URL }}" \
            -H "Content-Type: application/json" \
            -d '{
              "message": "Tests recovered: ${{ github.repository }}",
              "status": "resolve"
            }'
      
      - name: Fail job if tests failed
        if: steps.test_run.outcome == 'failure'
        run: exit 1

The "status": "resolve" message auto-resolves the Squadcast incident when tests pass. This prevents alert accumulation and keeps the incident queue accurate.

Runbooks Linked to Test Failures

Runbooks are one of Squadcast's strongest features for QA teams. When an incident fires, the responding engineer sees the runbook for that service inline.

For your CI test suite service, create a runbook with:

# QA Test Suite Runbook

## When This Fires
This alert means the automated test suite has failures.

## Quick Checks
1. Open the CI run URL in the incident description
2. Check which test file is failing (integration? unit? e2e?)
3. Check if this is a new failure or previously flaky test

## Common Causes
- **Integration tests failing**: Check if external services (Stripe sandbox, AWS) are degraded
- **E2E tests failing**: Check if staging environment is up at https://staging.example.com
- **Unit tests failing**: Likely a recent code change broke an assumption

## Escalation
- If you can't identify the cause in 20 minutes, escalate to the squad lead
- If external service dependency, notify the relevant team and create a separate incident

## Recovery Steps
1. Identify failing tests from CI logs
2. Check recent commits on this branch for related changes
3. Fix forward or revert the responsible commit
4. Re-run the test suite to confirm recovery
5. Add a post-mortem note if >10 tests failed

Link this runbook to your CI service. Every engineer who gets paged sees this context immediately.

On-Call Schedule Configuration

Creating Rotations

In Squadcast, schedules support multiple rotation types:

Weekly rotation — Simple seven-day shifts. Good starting point for most teams.

Custom rotation — Define shift length, rotation frequency, and override windows. Flexible for teams with variable availability.

Multi-layer schedules — Set a primary on-call and a backup. If the primary doesn't acknowledge within the escalation window, the backup is automatically paged.

Setting Up the Schedule

1. Go to Schedules → Create Schedule
2. Choose rotation type
3. Add participants
4. Define shift duration and rotation order
5. Set timezone (critical for distributed teams)

For QA teams that don't want 24/7 coverage on all alerts, use Squadcast's time restrictions in your escalation policy to limit after-hours paging to critical failures only.

Override Management

Team members can set coverage overrides for planned time off. Whoever takes on coverage during the override period receives alerts instead of the scheduled on-call.

The on-call calendar is visible to the whole team, so there's no ambiguity about who's responsible at any moment.

Incident Response Workflow

When a test failure fires in Squadcast, the incident lifecycle:

1. Triggered — Alert fires, on-call engineer is notified
2. Acknowledged — Engineer confirms they're investigating (clock stops on escalation)
3. Investigating — Active response underway
4. Resolved — Issue fixed, tests passing

During investigation, engineers can:

• Add timeline notes ("Found root cause: Stripe sandbox is down")
• Tag teammates to join the incident
• Link related incidents
• Update the incident's impact description

After resolution, Squadcast generates an incident report from the timeline, which becomes your post-mortem starting point.

SRE Metrics and Reporting

Squadcast tracks the SRE metrics that matter:

MTTA (Mean Time to Acknowledge) — How quickly does your team respond to pages? Target < 5 minutes for P1 alerts.

MTTR (Mean Time to Resolve) — From alert to resolution. Track this per service and per team member to identify patterns.

Alert frequency — How many incidents per service per week? Increasing frequency suggests systemic issues.

Escalation rate — How often do alerts escalate beyond the first responder? High escalation rates mean either responders aren't acknowledging or incidents are too complex for first-line response.

Find these in Analytics → Team Analytics. Filter by service, time range, or team member.

HelpMeTest + Squadcast

HelpMeTest runs continuous tests against your production and staging environments every few minutes. When a monitored test fails, it should trigger a Squadcast incident — not just a notification.

Configure HelpMeTest webhooks to POST to your Squadcast service webhook URL:

On failure:

{
  "message": "HelpMeTest: {{test_name}} failing in {{environment}}",
  "description": "Test: {{test_name}}\nError: {{error_message}}\nURL tested: {{test_url}}\nEnvironment: {{environment}}\nConsecutive failures: {{consecutive_failure_count}}",
  "status": "trigger",
  "tags": {
    "environment": {"value": "{{environment}}", "color": "#ffa500"},
    "source": {"value": "helpmetest", "color": "#0066cc"}
  }
}

On recovery:

{
  "message": "HelpMeTest: {{test_name}} recovered in {{environment}}",
  "status": "resolve"
}

With HelpMeTest running every 5 minutes, Squadcast incidents reflect real-time production health. Engineers are paged within minutes of a production regression, not hours.

Squadcast vs. PagerDuty vs. OpsGenie

Squadcast is the value pick for SRE-focused teams that don't need PagerDuty's extensive enterprise features. For QA teams embedded in SRE organizations, it's worth serious consideration — especially at its price point.

Getting Started

1. Create a Squadcast account at squadcast.com
2. Create your first Squad (team)
3. Build an escalation policy for your team
4. Create an on-call schedule
5. Create a "QA Tests" service
6. Link the service to your escalation policy
7. Copy the inbound webhook URL
8. Add the webhook to your CI pipeline and monitoring tools
9. Test end-to-end by triggering a deliberate failure
10. Write and link a runbook for common failure scenarios

The whole setup takes about an hour. After that, your team gets paged on real failures, auto-resolves incidents when things recover, and has a documented history of every incident for retrospectives.