Platform · Incidents & Alerting
Signals become incidents. Incidents become action.
A wall of threshold alerts is not monitoring — it is noise with a timestamp. SchemaPulse collapses related signals into one incident that carries its context, its history and its owner.
The pipeline
Signal → Alert → Correlation → Incident → Investigation → Action
- 01
Signal
A metric crosses a threshold, a replica falls behind, a cluster member leaves, a backup run finishes without verification. Raw, frequent, and on its own not worth waking anyone for.
- 02
Alert
A rule scoped to the instance and the metric decides whether this signal matters here. What is critical on a write primary can be expected on a reporting replica.
- 03
Correlation
Related alerts across members of the same cluster collapse into one incident. Correlation that ignores topology produces three incidents for one failover.
- 04
Incident
An object with severity, state, an owner, a comment thread and the full event sequence that produced it — not a notification that vanishes.
- 05
Investigation
The event history is attached, so the post-mortem is reading rather than reconstruction. Metrics, queries and topology events share the incident’s timeline.
- 06
Action
Routed to the tools your team already runs, with acknowledge and resolve available straight from the notification.
In the product
Alerts, and the incident they became
Incident · INC-2291 — correlated
Five raw signals, one incident, one page.
Rules
What you configure, and what it remembers
- Scope
- Per metric and per target — an instance, a cluster, or a project. Rules are not global thresholds pretending to fit every workload.
- Severity
- Assigned by the rule, so the page you get at 3am is one you agreed was worth it.
- State
- Open, acknowledged, muted, resolved. Every transition is recorded with who made it — a muted alert is a decision with an owner, not a gap.
- Mute
- Time-bounded and attributable, so silence has an expiry rather than becoming permanent by accident.
- Maintenance
- Scheduled windows suppress the expected, so the alerts that do fire keep their meaning.
- History
- Every firing, acknowledgement and mute retained, so a recurring problem is visible as a pattern rather than a series of surprises.
Correlation
Why one incident beats nine alerts
Without correlation
- Replica lag alert — billing-rs-2
- Membership change — orders-galera-1
- Buffer pool hit rate — orders-galera-0
- Query latency — digest a3f19c
- Connection spike — orders-galera-0
Five pages. Five people looking at five fragments of one event, each deciding independently whether it matters.
With correlation
- INC-2291 — orders-galera, elevated
- 5 contributing signals, sequenced
- Topology context attached
- Owner assigned, thread open
- Jira SP-418 linked
One page, one owner, and the reasoning already assembled — including which candidate cause the evidence actually supports.
Jira
An incident and its Jira issue stay one thing
Most integrations post a message and forget about it. The link between a SchemaPulse incident and a Jira issue is persistent and read in both directions: the incident holds the issue key, and every time you open it, SchemaPulse fetches the issue's current status,assignee and full comment thread from Jira and shows them alongside its own event history.
So the engineer working in Jira does not have to report progress back, and the DBA looking at the incident does not have to go and check. Neither system is the copy.
SchemaPulse incident
Read back from Jira, shown in the incident
Event history — both directions
- Create from the incident
- One action turns a correlated incident into a Jira issue, with its evidence and event history in the description. Creating it is itself recorded as an incident event, and a second attempt is refused rather than producing a duplicate.
- Status, read back
- The issue's current Jira status appears on the incident. Work moving in Jira is visible to whoever is watching the database.
- Assignee, read back
- Who owns it in Jira shows on the incident, so ownership is not tracked twice.
- Comments, both ways
- The Jira comment thread — author and text — is shown on the incident. Comments and status changes made in SchemaPulse are pushed to Jira, attributed to the person who made them.
- Reopen
- A recurrence can reopen the existing Jira issue rather than starting an unrelated one, keeping the history in one place.
- Deep link
- The incident links straight through to the issue in Jira, so nobody is searching by key.
Notifications
Fits the tools your team already runs
SchemaPulse consolidates database operations. It does not ask your engineers to watch another console alongside the one the rest of the org already lives in.
- PagerDuty
- Incidents raise and resolve PagerDuty alerts, and acknowledgement flows back — an incident acknowledged on a phone is acknowledged in SchemaPulse.
- Jira
- Push an incident to Jira as an issue with its evidence and event history attached. The link is kept, so the two stay in step.
- Slack & Microsoft Teams
- Posted to the channel that owns the service, with acknowledge and resolve available from the message.
- Webhooks
- A signed HTTP callback for your own runbook automation, status page or internal on-call system.
- Notification channels with test-send, and tokenised action links that work without a login.
- Scoped per project
- Routing follows organisation and project scoping, so a shared platform does not page the wrong team.