惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

C
Cybersecurity and Infrastructure Security Agency CISA
D
Darknet – Hacking Tools, Hacker News & Cyber Security
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
S
Schneier on Security
L
Lohrmann on Cybersecurity
S
Securelist
P
Palo Alto Networks Blog
SecWiki News
SecWiki News
T
Troy Hunt's Blog
H
Hacker News: Front Page
AWS News Blog
AWS News Blog
Latest news
Latest news
Hacker News - Newest:
Hacker News - Newest: "LLM"
NISL@THU
NISL@THU
The Hacker News
The Hacker News
F
Full Disclosure
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
大猫的无限游戏
大猫的无限游戏
O
OpenAI News
P
Proofpoint News Feed
Know Your Adversary
Know Your Adversary
G
GRAHAM CLULEY
博客园_首页
Attack and Defense Labs
Attack and Defense Labs
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Security Latest
Security Latest
云风的 BLOG
云风的 BLOG
K
Kaspersky official blog
WordPress大学
WordPress大学
www.infosecurity-magazine.com
www.infosecurity-magazine.com
宝玉的分享
宝玉的分享
L
LINUX DO - 热门话题
博客园 - 叶小钗
L
LINUX DO - 最新话题
Martin Fowler
Martin Fowler
N
News | PayPal Newsroom
Project Zero
Project Zero
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
PCI Perspectives
PCI Perspectives
月光博客
月光博客
IT之家
IT之家
Recent Announcements
Recent Announcements
T
The Exploit Database - CXSecurity.com
D
DataBreaches.Net
J
Java Code Geeks
酷 壳 – CoolShell
酷 壳 – CoolShell
Last Week in AI
Last Week in AI
Google Online Security Blog
Google Online Security Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis Monitor Aruba Central in Datadog How we centralize and remediate risks with Datadog Case Management Accelerate incident response with Datadog and ServiceNow Monitor your application and network load balancer logs Understanding Karpenter architecture for Kubernetes autoscaling Tools for collecting metrics and logs from Karpenter Monitor Karpenter with Datadog What your product data is actually saying Key metrics for monitoring Karpenter Securing Datadog’s platform in the AI age: The role of observability data Four ways engineering teams use the Datadog MCP Server to power AI agents Approaching your observability migration with the right mindset Meet the new Bits AI SRE: Deeper reasoning, twice as fast Key learnings from the 2026 State of DevSecOps study Use plain English to query your multi-cloud infrastructure in Resource Catalog Simplifying troubleshooting across the user journey with Datadog Synthetic Monitoring Protect your OCI resources with Datadog Cloud Security This Month in Datadog - February 2026 Amazon EC2 security: How misconfigured and public AMIs expand your cloud attack surface Enable end-to-end visibility into your Java apps with a single command Measure and improve mobile app startup performance with Datadog RUM Evaluating our AI Guard application to improve quality and control cost Identify untested code across every level of your codebase Make use of guardrail metrics and stop babysitting your releases Monitor Versa Networks SD-WAN performance in Datadog Improve performance and reliability with APM Recommendations Remediate transitive vulnerabilities faster with Datadog Software Composition Analysis Generate audit-ready vulnerability and compliance reports with Datadog Sheets Monitor Fortinet FortiManager performance in Datadog Improve test coverage across codebases with Datadog Code Coverage Move fast, don’t break things: Consistent testing standards at scale Enrich logs with ServiceNow CMDB context before routing to any SIEM or logging tool Monitor Lustre with Datadog Make faster, better product decisions with Datadog Product Analytics Surface and remediate runtime posture issues with Workload Protection Findings Protect agentic AI applications with Datadog AI Guard How to optimize JavaScript code with CSS Trace Google Pub/Sub workloads in Cloud Run with Datadog Detect human names in logs with ML in Sensitive Data Scanner How we cut our NLQ agent debugging time from hours to minutes with LLM Observability Debug PostgreSQL query latency faster with EXPLAIN ANALYZE in Datadog Database Monitoring Datadog acquires Propolis Unify and correlate frontend and backend data with retention filters Scale compliance across global frameworks with Datadog Cloud Security Monitor Arista VeloCloud SD-WAN performance with Datadog Building reliable dashboard agents with Datadog LLM Observability Simplify log collection and aggregation for MSSPs with Datadog Observability Pipelines Mitigation for Node.js denial-of-service vulnerability affecting Datadog APM Automate flaky test fixes with the Bits AI Dev Agent and Test Optimization How we built an AI SRE agent that investigates like a team of engineers Datadog integrations 2025 recap: Observability for AI, security, and hybrid cloud Design effective executive dashboards with Datadog Implement dbt data quality checks with dbt-expectations Bring faster visibility into AWS Lambda functions with remote instrumentation Troubleshoot faster with the GitLab Source Code integration in Datadog How Cambia Health Solutions saved $30,000 monthly with Cloud Cost Management and the Datadog Resource Catalog Normalize any logs for Cloud SIEM with Datadog's OCSF processor Optimizing Datadog at scale: Cost-efficient observability at Zendesk Detect, diagnose, and resolve network issues easily with CNM Network Health Connect engineering errors to user impact in early-stage products Cilium configuration for Kubernetes operations at scale Designing feedback loops for progressive delivery Ship features faster and safer with Datadog Feature Flags Choosing the right OpenTelemetry Collector distribution Route your monitor alerts with Datadog monitor notification rules Automate Cloud SIEM investigations with Bits AI Security Analyst Cloud threat detection: How to identify risky activity across control and data planes Collecting Kafka performance metrics Monitoring Kafka with Datadog Monitoring Kafka performance metrics
How to create an effective paging strategy
2025-03-26 · via Datadog | The Monitor blog
Addie Beach

Addie Beach

Empowered engineers and effective tools are the foundation of incident management, and having a solid on-call process can help facilitate both. In practice, however, many paging approaches have the opposite effect, often overwhelming responders and increasing burnout.

To create an effective paging strategy, organizations should focus responder attention on the most important issues and help facilitate a sense of ownership over them. When done successfully, this not only helps critical problems get resolved faster, it enables engineers to better understand how on-call work relates to both business goals and user satisfaction.

In this post, we’ll explore strategies for:

Design symptom-based pages and monitors

Figuring out what to alert on can be a difficult balance. Monitors that are too high-level risk missing critical problems until they’ve already spiraled out of control, while noisy alerts can quickly lead to alert fatigue. You need to alert on the right issues, at the right sensitivity, and to the right people.

To do so, you should first aim to page on monitors that detect user impact. Because teams are often pushed to catch problems before they reach users and conduct fast root cause analysis, it can be tempting to expedite this process by alerting on system health metrics that seem to point to what’s going wrong. These metrics may include CPU or memory usage reaching a certain threshold, for example. However, given the wealth of downstream and upstream impacts in distributed systems, these health metrics give a poor sense of severity as they might not point to the true root cause in the first place. Additionally, they tend to generate noise that can distract from critical issues—or even miss them altogether.

By contrast, paging on user-facing symptoms keeps your response grounded in issues that are actively causing pain. These issues can be anything from noticeably slower loading times that increase user frustration to errors that completely prevent users from interacting with your app. In addition to more quickly surfacing critical incidents, this approach helps minimize the burden of on-call work on your team by cutting down on the amount of time they spend responding to hypothetical or unimportant problems. When your team members have a better understanding of user impact, they’re more likely to have a better sense of the importance of the issues that they’re working on and feel more invested in on-call work. Finally, these metrics often correlate more directly with SLOs, such as service availability, making it easier to prioritize issues based on business impact.

User-facing metrics you’ll want to focus on in your pages include:

  • Performance metrics, which can include both overall service latency as well as more granular metrics like Core Web Vitals.
  • Error metrics, like the percentage of 5xx server errors returned over time. You may need to pay careful attention to the severity you use for these metrics. For example, 4xx client errors can also be useful to alert on, but you’ll want to use a higher threshold as smaller spikes may simply be a result of user error.
  • Throughput metrics, usually consisting of the number of queries or requests being processed by your app. With throughput, you’ll often want to add downtimes to account for predictable dips in user activity, such as during app maintenance or certain holidays.

Using user-facing metrics to determine high-priority monitors can help you decide what route to notify responders through. Alerts that are sent directly to a mobile phone or dedicated paging device are the most disruptive for on-call team members, especially when they occur late at night or otherwise outside normal work hours. Ideally, on-call responders shouldn’t receive more than two of these pages per shift.

Instead, lower-priority health alerts that are more useful for long-term maintenance can be sent to ticketing or task management systems, such as Datadog Case Management. This enables them to be tracked without immediately disrupting other work. Datadog helps you achieve this by giving you the ability to fine-tune your notification settings directly within the monitor itself.

The notification configuration and automation options for a monitor.

Establish on-call roles and responsibilities

Customizing your monitors helps you determine when to page, but how do you know who should be paged and what is required of them? A key part of the incident response process is determining who owns which issues, as well as when issues need to be delegated or escalated. Doing so helps you ensure that on-call work is fairly distributed across teams, recurring problems are prevented, and quality of response is prioritized over the number of pages responded to—all of which can help prevent confusion among on-call team members. Additionally, when your team members know who to contact when issues rise in severity, they’re able to resolve the problem faster, prevent future ones, and build trust with users.

To set clear lines of responsibility, you should establish the idea that being paged means owning the incident response process end to end, from initial triage to resolution and postmortem. With smaller issues, this may mean that the on-call team member resolves the issue themselves. For example, let’s say they’re paged about a sudden spike in latency on one of their services. Investigating the issue reveals that it stems from high CPU usage, which they can resolve by scaling up the problematic cluster. From here, they can determine whether this case fits their team’s criteria for autoscaling to prevent future issues.

For pages that escalate to incidents, however, the on-call team member usually becomes the incident commander. Once they acknowledge the page, this team member will then declare the incident and start performing initial triage activities. While not necessarily responsible for carrying out all remediation activities, they are responsible for making critical decisions about the incident, including the severity level, other necessary responders, and a mitigation plan.

Many incidents require collaboration from owners of other services, subject matter experts, and customer communication specialists. The idea that pages require an immediate response should be an important organization-wide standard; to uphold it, you should only page other responders for high-urgency matters. When paging, key details about an incident should include:

  • The current impact
  • Why you think their service is involved in the incident
  • What you need them to do

For issues that aren’t as urgent, you should go through normal communication channels, such as your organization’s messaging platform.

Additionally, for complex incidents, engineers with more experience coordinating large-scale incidents may take over the incident commander role. Depending on your organization’s tooling and processes, these responders should be paged automatically when the severity of an incident is established. In these situations, the original on-call commander often remains part of the incident response process to help provide context and troubleshoot issues related to their service.

It may not always be the case that an on-call team member can immediately respond to pages, as anything from personal emergencies to mobile network problems can present unexpected challenges. When the designated on-call team member can’t be reached, escalation policies should help you determine who will be paged next. Many paging systems will automatically escalate issues based on the policies you define, contacting the next team member in line if a response is not received in time. Teams should come up with a time limit for page acknowledgment that ensures issues are addressed without causing unnecessary stress—usually this is between five and 15 minutes.

To help on-call team members keep track of the work that they’re responsible for, whatever paging methodology you use should go hand in hand with the tools you use to manage issue remediation and other on-call activities. Otherwise, on-call team members can quickly become overwhelmed and lose track of work, especially when it comes to larger incidents with lots of follow-up tasks or long post-resolution analyses.

One way to ensure that your work is effectively organized is to use cross-platform features and integrations. By automatically sharing data from your paging systems with communication tools like Slack and work management tools like Jira, you can easily triage alerts, document key details, and loop in other responders. Correlating and relaying findings between different platforms can be a major source of both confusion and time loss during incident response. By having your troubleshooting data in the same place where your incident management tools live, you can easily pivot between the two in the same app. Then, you can send insights directly to your communication tools and ensure that no context is lost between responders.

Datadog Incident Response helps you easily alert, track, and investigate issues within a single platform. First, Datadog On-Call enables you to manage your paging strategy on a granular level. For example, you can see an overview of your longest-running pages and most-paged monitors—areas where you can potentially optimize your alerts to focus on more relevant metrics or to be less sensitive.

The Analytics page in Datadog On-Call, with statistics such as frequently page monitors, users, and services displayed.

When an on-call team member is paged, On-Call enables them to easily acknowledge the page, evaluate the severity, and begin investigating. Teams can create dynamic runbooks within Datadog Notebooks, helping on-call responders quickly determine the first steps they should take to resolve the issue. Responders can also easily pivot from the page details to relevant monitors and service metrics to view critical context around the problem.

For larger issues, on-call team members can declare incidents directly from a page. Within an incident, Datadog automatically collects all context related to an incident, including conversations or meetings that may be happening on other platforms. You can easily choose key aspects of these discussions to highlight within your incident timeline alongside other critical actions.

The timeline for an incident in Incident Management, showing a page being received and escalated to an incident.

To make handling high-urgency issues even easier, you can access incident response features directly within the Datadog mobile app. With the app, you can pivot from receiving a page to triaging the issue and declaring an incident without ever leaving your phone. The app also includes access to Datadog Notebooks, so you can begin consulting your runbooks and strategizing a response right away. By the time you pivot to your computer for in-depth investigation, you’ve already alerted the relevant responders and kicked off communication.

When you do need to pivot between platforms, Datadog provides over 1,000 integrations to make this process seamless. These include Slack, Teams, Zoom, and Jira. And once an issue has been resolved, you can access Datadog Case Management to organize any follow-up tasks and delegate them as needed.

Optimize your paging strategy for better incident response

On-call shifts have the potential to burn out your team members, lowering productivity and potentially leading to more issues going unresolved or overlooked. Additionally, recurring issues due to inefficient on-call and incident management processes often mean higher costs in the long run.

By refining your alerts to highlight problems that have the most customer impact and integrating features that help your team members track the entire lifecycle of an incident, you can empower engineers and keep their focus on high-impact work. Effective on-call strategy and tools require continuous fine-tuning, but having clear processes in place can help your team members feel confident and in control even in the face of ever-changing situations.

Datadog Incident Response helps you better manage your on-call strategy, from the initial page through remediation and post-incident analysis. You can get started with Datadog On-Call using our documentation. Or, if you’re not yet a Datadog user, you can sign up for a 14-day free trial.