Failure classification you control
Incident severity maps to "counts as failure" or "informational" through rules you configure — not a fixed severity scale that doesn't match how your teams triage.
← Use Cases
USE CASE
moasy.tech for Heads of Engineering
Reliability is a process question, not a vibe — and the process looks different on every team.
Mean time to restore and change failure rate only mean something if you trust how "failure" got defined — and that definition rarely fits every team the same way. moasy.tech lets each team configure its own incident-to-deploy correlation window and failure classification, with an org-wide default as fallback, so the number reflects how that team actually operates.
A typical week
When MTTR ticks up for a team, you don't start with a guess — you check which configuration is actually producing that number: is the incident-to-deploy correlation window too tight, is the clock starting at acknowledgement instead of the incident itself. Once a team's process genuinely changes — say they move triage to a different tool — that correlation window is a config change, not a quarter-long migration. And when a postmortem needs the receipts, the Timeline shows exactly who changed what config, and when.
Why it helps
MTTR with the trigger you choose
Start the clock at incident trigger or at acknowledgement — whichever matches how your team actually responds.
Precedence that makes sense
Team-level config beats org-level config beats system default — override where you need to, inherit everywhere else.
Auditable, not opaque
Every DORA number echoes back exactly which configuration produced it — nothing is computed off a rule nobody can see.
No double-counted deploys
Connect more than one CI/CD tool to the same team, and moasy.tech catches the risk of counting the same deploy twice on its own — the reliability number stays trustworthy even with a messy toolchain.