Skip to main content
Flashduty

Turn Alerts Into Actionable Incidents

After you ingest 100+ sources, Flashduty standardizes, groups, and routes alerts automatically, so responders see less noise and acknowledge faster. MTTA (Mean Time to Acknowledge) becomes more predictable from the first page. With 9 notification channels and multi-level escalation, you can reliably reach the right on-call owner in the tools your team already uses.

1.0Integration

Connect Your Monitoring Stack in Minutes

Ingest signals first, standardize once, and reuse the same normalization, grouping, routing, and escalation flow end to end.

activemq
aliyunARMS
aliyunSLS
AWSCW
azureMonitor
BaiduBCM
Blackbox
clickhouse
cloudflare
consul
Docker
elasticsearch
etcd
gitlab
grafana
harbor
http
HuaweiCES
jira
kafka
Kubernetes
l_statecloud
Linux
loki
memcache
meraki
minio
mongodb
mysql
NET
nginx
nightingale
opmanager
oracle
OS
PING
postgresql
rabbitmq
redis
servicenow
slack
solarwinds
splunk
tencentCM
tomcat
uptime-kuma
zabbix
zilliz
zookeeper
50+integrations

From common monitoring stacks to collaboration tools, teams can ingest alerts without rewriting payloads per source.

View all integrations

Configure Once, Reuse End to End

Policy reuse end to end with one normalization and escalation chain

Migrate Without Rebuilding Everything

Lower migration overhead with PagerDuty-compatible ingest paths

Deliver Normalized Events Across Channels

Normalized events reach nine channels—including Feishu, DingTalk, and WeCom—so monitoring flows straight into paging.

Common Monitoring and APM Sources Ready

PrometheusGrafanaCloudWatchDatadogSentry

What's covered

Open Source

Prometheus / Grafana / Zabbix

Cloud

AWS / Alibaba Cloud / Tencent Cloud / Huawei Cloud

APM

Datadog / Sentry / Dynatrace

Collaboration

Feishu / DingTalk / WeCom / Slack / Teams

2.0Normalize & route

Normalize, Enrich, and Route to Owners

Turn raw alerts into computable incident objects, enrich ownership context, then route to the team that can act immediately.

{
  "alertname": "API latency spike",
  "instance": "checkout-api:9090",
  "labels": "env=prod, region=cn-hz",
  "severity": "critical",
  "startsAt": "2025-04-13T04:12:00Z"
}
{
  "trigger": "CPU > 95% on db-master",
  "host": "db-master-01",
  "hostgroup": "MySQL Cluster",
  "priority": "disaster",
  "timestamp": "1713010320"
}
{
  "AlarmName": "HighErrorRate",
  "Namespace": "AWS/Lambda",
  "MetricName": "Errors",
  "StateValue": "ALARM",
  "Region": "ap-southeast-1"
}
{
  "ruleName": "MemoryPressure",
  "folder": "Infrastructure",
  "orgId": "1",
  "state": "alerting",
  "dashboardUID": "infra-mem-01"
}

Normalize

Map source-specific fields into one canonical event schema.

Enrich

Attach context from service catalog, CMDB, and on-call ownership rules.

Route

Dispatch incidents by service ownership, severity, and time-window policy.

serviceapi-gateway
teamCore SRE
severityP1
runbookcheckout-latency-v2

Faster handoff

ownership context is attached on ingest, not guessed in chat

More accurate dispatch

severity and time windows drive day/night routing paths

Clearer reviews

mapping and routing decisions remain fully auditable

3.0Noise aggregation

Collapse Noise Into One Incident Thread

Collapse duplicate, cascading, and flapping alerts into one actionable incident thread so responders acknowledge once and move.

CPU > 90%
API latency spike
Gateway timeout
Error budget burn
Disk I/O sat.
OOM killed
#9BD163

Advanced Mode - Alert Threshold Test 2 / vm_cluster - 10.99.1.106-log-collector

Flashduty
Closed1 minAlert events: 2
Flashduty Workspace·Apr 14 15:08:19

Far fewer duplicate pages from shared-root-cause alerts

Responder focus shifts to the incident thread with real customer impact

Faster acknowledgment because one ownership action starts execution

4.0Delivery channels

Reach Teams Through the Channels They Use

Follow how teams really communicate: low-friction channels for daily collaboration, hard-fallback channels for critical incidents.

Phone
Email
SMS
Feishu
DingTalk
WeCom
Slack
Microsoft Teams

Native IM Delivery

Native Feishu, DingTalk, and WeCom delivery without mail-forward hacks.

Hard-Fallback Channels

SMS and phone provide hard fallback so critical pages do not disappear into feeds.

Personal Preferences

Each responder tunes channel mix and intensity for quiet hours versus must-deliver pages.

5.0Dispatch & escalation

Dispatch by Policy, Escalate Until Acknowledged

Dispatch to the current owner first, then escalate by severity and time-window policy until someone explicitly acknowledges.

P1Critical
servicecheckout-api:9090
time02:30 AM
P3Info
servicecms-backend
time10:15 AM
P2Warning
serviceapi-gateway
time18:45 UTC
Policy Engine
Severity
Time window
Service ownership
Escalation tier
Primary/backup role
More...
P1 · After Hours
Phone
L1
SMS
L2
PhoneSMS
L3

The outcome is not just message delivery, but explicit ownership by someone who can act.

P3 · Business Hours
FeishuDingTalkWeCom
L1

The outcome is not just message delivery, but explicit ownership by someone who can act.

P2 · Follow-the-Sun
Slack
L1
Email
L2

The outcome is not just message delivery, but explicit ownership by someone who can act.

Clear ownership with primary on-call taking the first handoff

Predictable escalation with transparent timing and next recipients

Lower miss risk through automatic primary/backup/fallback relay

Frequently Asked Questions

Explore More Products

Less noise. Faster recovery.

Start free—no credit card. Book a demo to see your alerting pipeline end to end.