Skip to main content

FM-KED-000 Getting Started


The Finmars Known Error Database is a curated registry of recurring and well-understood operational issues observed in Finmars environments, together with documented recovery procedures and practical guidance.

Its purpose is not to list every possible failure, but to capture patterns that are already known, reproducible, and solvable through established algorithms. Each entry describes the symptoms, scope of impact, severity, and an expected recovery path based on real operational experience.

This document serves three audiences at once

  • operators who need fast orientation during incidents
  • customers who want transparency and predictability
  • support teams who require a shared operational memory

Every known error in this database is classified by severity and recovery class, allowing readers to understand both the business impact and the typical effort required to restore normal operation. Where possible, step-by-step recovery instructions are provided to reduce response time and avoid unnecessary investigation.

Issues that are not present in this database are considered unknown by definition. Such cases may require discovery, diagnostics, or architectural analysis and are handled outside the scope of predefined recovery commitments.

The Finmars Known Error Database is a living document. It evolves with the platform, operational experience, and lessons learned from real incidents. Its goal is clarity, not completeness. Reliability, not illusion.

Each known issue carries two orthogonal markers:

  1. Severity – impact on the business or system
  2. Recovery Class – expected effort and time to restore service

Severity Levels (Impact-based)

S1 — Critical

  • System unusable or data integrity at risk
  • No viable workaround
  • Immediate attention required

S2 — High

  • Core functionality degraded
  • Workarounds exist but are painful
  • Business impact is noticeable

S3 — Medium

  • Partial feature loss
  • Clear workaround available
  • Limited operational impact

S4 — Low

  • Cosmetic or non-blocking behavior
  • No impact on business operations

Severity answers the question:
“How bad is this for the user?”

Recovery Class A — Quick Fix

  • Expected resolution: under 1 hour
  • Fully documented procedure
  • Typical for routine maintenance issues

Recovery Class B — Standard Recovery

  • Expected resolution: up to 4 hours
  • Known issue with multiple steps or validation
  • Usually fits within monthly support window

Recovery Class C — Extended Recovery

  • Expected resolution: up to 1 business day
  • High complexity or cross-component dependency
  • Not fully covered by standard support

Recovery Class D — Exploratory

  • Resolution time unknown
  • Partial or missing diagnostic data
  • Discovery and investigation required

Recovery class answers the question:
“How long does it usually take when things go normally?”

How it looks in registry

Example

  • Issue ID: FM-KED-###
  • Title: Background jobs stuck in pending state
  • Severity: S2 — High
  • Recovery Class: B — Standard Recovery
  • Estimated Recovery Time: up to 4 hours
  • Covered by Monthly Support: Yes
  • Resolution Algorithm: documented

For an unknown issue:

  • Severity: S1 — Critical
  • Recovery Class: D — Exploratory
  • Covered by Monthly Support: No
  • Notes: subject to separate agreement
Back to top