Accepted
The provider API accepted the request. This proves only the injection boundary.
Alert-path assurance, from signup onward
From first heartbeat to evidence you can defend.
AlertProof helps you define the route an alert should take, verify each observable hop, and see when a critical path is failed, inconclusive, stale, or still untested.
Already have an account? Sign in. If you are already signed in, these account routes return you to your product journey.
Organization workspace
Northstar Ops
Understand what is configured, what the latest evidence proves, and where your team should go next.
Alert pathsDefine or manage a pathDescribe the expected route and required evidence.
IntegrationsConnect an integrationAdd a provider using the secure credential flow.
AssuranceView assuranceInspect freshness windows and normalized changes.
Critical-path assurance0 / 0
No protection or delivery claim can be made until a critical path has completed verification evidence.
The current product journey
Start small. Build assurance one honest step at a time.
Create the tenant boundary first, prove the basic ingress with a heartbeat, then model and verify the alert paths that matter. You can begin before connecting any third-party provider.
- 01
Create your workspace
Register, verify your email, name an organization, then add the first project and environment you want to protect.
- 02
Send a first heartbeat
Create a heartbeat check and make one HTTP request. The token is shown once; the workspace opens only after AlertProof stores the event.
- 03
Define an Alert Path
Describe the ordered source, route, and destination, the assurance required at each node, latency limits, schedule, and freshness window.
- 04
Run and inspect verification
Use a controlled synthetic destination by default. The run trace shows its injection point, strategy, observed timestamps, latency, and first divergence.
- 05
Maintain ongoing assurance
Use recurring verification and the workspace overview to separate fresh passes from failures, insufficient visibility, expired evidence, and paths never run.
Northstar Ops
Send your first heartbeat
Create a heartbeat check, then send one request to prove it works.
Copy this token now — it is shown only once
••••••••••••••••••••curl
curl -X POST https://alertproof.com/v1/heartbeats/••••••Heartbeat observedThe event is stored for this check.
Protected alert path
Payments P1
CriticalityCritical
Assurance window7 days
Evidence freshnessNever verified
Expected graph
- 1JSM canary inputIntegration · Required assurance: CreatedInjection point
- 2Payments responderResponder · Required assurance: Routed
- 3Synthetic webhookDestination · Required assurance: Delivered
Explicit evidence semantics
A green request is not a delivered alert.
AlertProof records the strongest level it actually observed. Provider API acceptance is never treated as end-to-end delivery, and missing visibility remains visible.
Created
The expected downstream alert or incident object was independently observed.
Routed
The observed service, team, responder, priority, or escalation matched the expectation.
Delivered
A controlled destination received the uniquely correlated synthetic message.
Human acknowledged
A named person explicitly acknowledged the test. Delivery alone does not imply this.
Verification run
Payments P1
StatusInconclusive
InjectionJSM canary input
StrategyRoute test
- 1JSM canary inputEvidence: Created · 12:14:03.142 · 184 msObserved
- 2Payments responderEvidence: Routed · 12:14:05.281 · 2,139 msObserved
- 3Synthetic webhookEvidence: Delivered · observed timestamp —Missing
Outcomes stay distinct
Know whether evidence is absent, uncertain, or expired.
- Inconclusive
- AlertProof lacks enough visibility to prove either success or failure. It is never promoted to a pass.
- Stale
- A completed result exists, but it is outside that path's required assurance window.
- Never run
- No finished verification evidence exists for the path. Configuration alone is not proof.
Ongoing assurance
The workspace shows what needs attention now.
Latest finished outcomes stay separate from work in progress. Freshness is evaluated against each path's assurance window, and a never-run path remains in the denominator rather than disappearing.
- Filter alert paths by passed, failed, inconclusive, stale, or never verified
- Open a completed run to inspect hop-by-hop observations
- Review normalized configuration changes without treating connection health as delivery proof
Alert paths
5 defined
5 enabledPassed within window1
Failed1
Inconclusive1
Stale evidence1
Never verified1
Latest assurance outcomes
Payments routePayments / Production
PassingPassedData export routeData / Production
StaleOutside required windowExisting comparison workflow
Compare Opsgenie and JSM behavior—not just object names.
When you have stored Opsgenie baseline and JSM target runs, AlertProof compares acceptance, severity, team or responder, escalation destination, downstream destination, and resolution as independent assertions.
An absent observation stays inconclusive. A different observed behavior is a fail. Matching evidence is a pass.
No paid provider account is required to understand or begin using AlertProof.Create your organization and complete heartbeat onboarding first. Provider credentials are needed only when you choose to connect and test that provider.
Opsgenie → JSM
Migration behavior comparison
AssertionResultOpsgenieJSM
AcceptancePassObservedObserved
Team / responderPassPaymentsPayments
Downstream destinationFailmigration-sinkdifferent-sink
ResolutionInconclusiveNot observedNot observed
Begin with the product you can use today
Create a workspace. Send a heartbeat. Build proof from there.
Start with organization and heartbeat onboarding; connect alerting providers only when you are ready to verify those paths.