Temperstack
Main WebsiteFeaturesPricingBlogAbout usRequest a Demo
  • Overview
    • What is Temperstack?
    • Use Cases
  • User Managment
    • Getting started as Admin
      • Inviting Users
      • Mapping multiple services to a Team
      • Single Sign-On (SSO)
      • Customising ALCOM Audit & scanning
    • Getting Started as a User /Responder
    • Managing profile & contact details
  • Integrations
    • Integrating your Observability tools
      • Setting up AWS Integration
        • Multiple AWS Account Integration
        • IAM Setup Guide
          • Creating IAM User: Temperstack with Policy
          • Creating IAM Role: Temperstack with Policy
      • Setting up Microsoft Azure Integration
        • Creating Access for Temperstack in Azure
      • Setting up Google Cloud Platform Integration
        • Creating Access for Temperstack in GCP
      • Setting up Datadog Integration
        • Creating Access for Temperstack in Datadog
        • Managing resources with Datadog
      • Setting up NewRelic Integration
        • Creating Access for Temperstack in NewRelic
        • Managing resources with New Relic
      • Setting up Splunk Integration
        • Creating Access for Temperstack in Splunk
        • Managing resources with Splunk
      • Setting up Appdynamics Integration
        • Creating Access for Temperstack in Appdynamics
        • Managing resources with Appdynamics
      • Setting up Dynatrace Integration
        • Creating Access for Temperstack in Dynatrace
        • Managing resources with Dynatrace
      • Setting up Oracle Cloud Infrastructure
        • Creating Access for Temperstack in OCI
    • Integrating Custom Alerts & Other Alerting sources
      • Webhook Integration
      • Ingesting Emails as alerts
      • Integrating alert listeners from other observability tools
  • Alert routing & Response Managment
    • On-call scheduling and Escalation Policies
    • Setting up Services
    • Alert notification channels
      • Integrating Slack channels
      • Integrating MS Team
    • Mapping resources to Services
      • Rule based resource to Service Mapping
      • Using AI suggested mapping rules
    • Testing Alerting and Notifications
    • Responding to Alerts
  • Monitoring
    • Setting up and maintaining Comprehensive alerting
      • Alerting Templates- metrics & customisation
      • ALCOM and identifying monitoring gaps
      • Programmatically setting up missing alerts in your Observability tool
      • Alert noise Reduction & Optimisation
  • Uptime Monitoring
    • Real time Availability Monitoring
  • Incident analysis & communication
    • External and Internal service Status Pages
      • Instruction to migrate subscribers from Statuspage
  • AI-Powered Issue Resolution
    • AI powered contextual Runbooks
    • Incident command - alert grouping by incident
    • AI Powered Root cause Identification
  • Reporting & Governance
    • Temperstack Dashboard
    • SLO Dashboard
    • MTTA MTTR
  • Billing & Help
    • FAQs
    • Support
Powered by GitBook
On this page
  • Who is a Responder?
  • How to Get Started as a Responder
  1. User Managment

Getting Started as a User /Responder

Who is a Responder?

A responder is an on-call engineer responsible for acknowledging and resolving alerts for assigned application services. As a responder, you play a critical role in incident management, ensuring the stability and reliability of the application services you oversee.

Responsibilities of a Responder:

  1. Acknowledging and Assessing Incidents: Recognize and evaluate the severity and impact of the incident.

  2. Taking Immediate Action: Implement measures to mitigate the impact of the incident.

  3. Investigating Root Causes: Analyze the underlying causes of the incident.

  4. Implementing Fixes or Workarounds: Apply necessary fixes or temporary solutions to resolve the incident.

  5. Communicating Status: Keep stakeholders informed about the incident status and progress.

  6. Documenting the Incident and Response: Record details of the incident and the actions taken for future reference and learning.

  7. Participating in Post-Incident Reviews: Engage in reviews to discuss the incident and identify improvements.


How to Get Started as a Responder

Scenario 1: Existing Temperstack User

  1. Create an On-Call Policy:

    • As an existing Temperstack user, start by creating an on-call policy.

    • Add yourself as an on-call engineer and include other responders if escalation is required.

  2. Map to Application Services:

    • Map the on-call policy to the application services where you will be the primary responder.

    • Assign the set of resources to the respective application services.

Read more on On-call Policy and Escalation in this guide. On-call scheduling and Escalation Policies

Read more on Setting and Mapping to services in these guides: Setting up Services

Mapping resources to Services

  1. Incident Response Workflow: When an incident occurs, such as an issue with the resource "fetch_gcp_resources_dlq" mapped to the application service named "Payments":

  • The application service is linked to the on-call policy "NewServiceOncallPolicy"

  • As the on-call engineer, you will be notified, typically through voice notification.

  • You are responsible for acknowledging and addressing the incident promptly.

Scenario 2: New Temperstack User

  1. Receive an Invitation:

    • If you do not have access to Temperstack, the admin of your organization will navigate to the Manage Organization page and send you an invitation.

    • Accept the invitation link to become a Temperstack user.

  2. Follow the Same Workflow:

    • Once you have accepted the invitation and gained access, follow the same steps as outlined in Scenario 1.

Last updated 10 months ago