Loading...
Loading...
Prioritized incidents with one clear next action.
Loading...
Related alerts auto-grouped into operational incidents. Active incidents are still receiving new alerts; quiet incidents are ready for review.
Loading...
At-a-glance health: volume, forward rate, delivery, AI spend, top sources.
Loading...
Why each alert was forwarded or skipped. Click a reason to filter; expand a row for the full decision chain.
Loading...
Loading...
Loading...
What happened on the last shift, and who changed what. The brief is markdown, ready to paste where the next shift reads.
What an alert costs on the way in. Matching alerts are still ingested, classified and forwarded — they just skip the model, or the investigation, or both.
While active, alerts matching the criteria are not forwarded. Events are still ingested, deduplicated, and analyzed.
Loading...
Weekly recurring mute windows (e.g. weekend maintenance). Matching alerts are silenced automatically while a window is active.
Loading...
Create a scoped source credential and verify the complete ingest path.
Inspect alert identity, field coverage, recovery matching, schema drift, and response hygiene. This view never changes source configuration.
Loading...
Choose a supported channel, test it, and create a forwarding rule in one guided flow.
Loading...
Paste a raw alert payload and see what WebhookWise would extract and decide — which adapter parses it, the alert identity, and which rules/silences would match. Nothing is queued, analyzed by AI, or saved.
Paste a payload and click Test to see how WebhookWise would handle it.
Surface zombie rules (gone quiet), pure-noise rules (never forwarded), and flapping rules (oscillating near threshold). Read-only over existing data.
Loading...
Measure alert noise, review safe recommendations, and apply reversible optimizations.
Loading...
Delivery, processing, and AI problems that need operator attention.
Loading...
Resolved-incident summaries awaiting review before they feed the AI knowledge base (RAG).
Loading...
Repeated work that lacks a proven runbook or complete resolution evidence.
Loading...
Every outbound intent and its fate — filter the outbox, inspect the last error, replay dead letters.
Loading...
Loading...
Live-tunable policy values. The effective value is the override when set, otherwise the environment default.
Changes take effect across all processes within about 1 minute (pub/sub + periodic refresh); no restart is required.
Loading...
How an alert travels through WebhookWise, and where each job gets done.
Point Grafana, Prometheus, Zabbix or any JSON webhook at WebhookWise. Use per-source credentials from the setup wizard, so a leaked key never exposes more than one source.
Match on keywords and severity, deliver to Feishu or any webhook. Try a real payload in the sandbox before a rule goes live.
Every alert passes eight suppression gates — dedup, silence, storm, budget and more. The trace records which gate stopped it, so "why didn't I get notified" always has an answer.
Silence known noise by dimension, schedule maintenance windows, and check silence ROI to see what each rule actually suppressed.
Related alerts group into incidents. Acknowledge, assign, resolve — an AI recap can post on resolve, and the handoff brief summarizes your shift for the next one.
A read-only MCP server exposes alerts, traces, incidents and cost to any MCP client. The built-in agent-guide resource documents every tool; deep investigations land under Investigations.
claude mcp add --transport http webhookwise \ https://<your-host>/mcp/ \ --header "Authorization: Bearer <API_KEY>"
Every field is optional. Resolve now and complete the record later if the incident is time-sensitive.
Used for read-only requests such as the alert list, AI cost, and forward rule list.
Used for write requests such as re-analysis, manual forwarding, retries, and saving/deleting forward rules.
API_KEY and ADMIN_WRITE_KEY are saved in this browser until you clear them. Use “Clear credentials” to remove both. They are never written to server config.