Checklist · Hosting and Recovery
Alert Severity Matrix: Trading, Payments and Back Office
Classify trading, payment and reporting incidents by observed impact, uncertainty and urgency, with owners and evidence required for escalation or recovery.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
An alert severity matrix connects observed impact to a response owner and escalation path. Assess affected services, financial integrity, scope, duration and available workarounds. The same technical signal can justify different urgency in different contexts, so document the reason for the classification and reassess it as evidence changes.
Start with symptoms and affected obligations
An alert names a signal; an incident record explains what that signal means to users or operations. A stopped quote stream might affect one inactive instrument or every actively traded instrument. A payment mismatch might be a delayed report or evidence of duplicate credits. Initial uncertainty belongs in the record rather than being hidden behind an overly precise label.
Google SRE distinguishes user-visible symptoms from internal causes and warns that noisy paging can make meaningful signals harder to notice. Use a small set of actionable classifications. Assign the person who can coordinate the response and the specialist needed to evaluate business impact, even when they are different teams.
Sources for this section
Specify the decision behind each severity
Define what requires immediate coordination, what permits a scheduled investigation and what can be handled as routine work. Consider whether clients can act on stale information, whether balances may be wrong, whether an external deadline exists and whether a safe workaround is available. Avoid using revenue or user count as the only factor: a small integrity error can deserve urgent containment.
Keep support contract labels separate from internal severity. A provider may require evidence or classify the issue differently. Record the mapping and escalation route without claiming that an internal critical label creates a contractual restoration deadline. Name who can change severity, communicate impact and authorize restrictions on affected workflows.
Review severity as knowledge improves
Record initial classification, current classification and the evidence behind each change. Lowering severity should follow confirmed containment or restored service, not the absence of new complaints. Increasing severity should not require proving the full cause when credible evidence shows growing impact.
Use the later incident review to test the matrix. Did an alert reach someone with the right access? Was the runbook actionable? Did an apparently low-impact report delay conceal a ledger issue? Google's postmortem guidance supports learning from contributing conditions; adapt the matrix through specific changes rather than adding more undifferentiated urgent alerts.
Sources for this section
- Google SRE: blameless postmortem culturesre.google
Example: three signals with different investigations
The following fictional classifications illustrate reasoning, not a universal severity policy or a supplier response promise. Each record includes an unresolved question and a next action. If new evidence changes the impact, the coordinator records a new classification without erasing the earlier one.
| Signal | Impact evidence | Initial action |
|---|---|---|
| Prices stopped for active instruments | Clients may see stale quotations | Immediate trading-operations coordination and safe-state review |
| Statement export delayed | Trading and balances verified; deadline tomorrow | Assign reporting owner and monitor backlog |
| Payment callback repeated | Duplicate credit not yet ruled out | Preserve event IDs, inspect ledger and contain affected automation |
Implementation checklist
- Record affected service, clients, obligations and current uncertainty.
- Assign a coordinator, technical owner and business decision owner.
- Map internal severity to the actual supplier support process.
- Preserve reclassification reasons and verify recovery before closing.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.