The Monthly SLAs page should include the ability to create, search, update, and delete Clients, based on User Roles defined in STANDARDS.md; and the ability to create, search, update, and delete Monthly SLAs, based on User Roles defined in STANDARDS.md. Monthly SLAs should also include a Generate Report button for users with Write or Admin role.
Clients include a General section with Company Code and Name; a System Availability section with System Availability SLA (a Percent); and, an End-to-End Response Time section with Web Application SLA (Enabled, and a Percent when Enabled = TRUE), Web Service SLA (Enabled, and a Percent when Enabled = TRUE), and Message Queue (Enabled, and a Percent when Enabled = TRUE). The Client's Company Code should be unique, and can serve as its ID for other entities to employ as a Foreign Key. Clients cannot be deleted if they are linked to one or more Monthly SLAs.
A Monthly SLA includes a General section; a System Availability section; an End-to-End Response Time section; and an Incidents section.
The General section should include Client (a list), Month (a list), Year (a list). The Month list should include all months. The year list should include 2026 through 2035.
The System Availability section should include Minutes in Month (number), Planned Outage Minutes (number), Unplanned Outage Minutes (number), Total Transactions (number), 5xx Outside of Outages (number), >5s Outside of Outages (number), Total Penalized Minutes (number), Contractual SLA (percent), Actual SLA (percent). Minutes in Month should be readonly and calculated based upon the selected Month and Year. Planned Outage Minutes and Unplanned Outage Minutes should be readonly and populated automatically from Outages by summing the outage minutes for all Planned and Unplanned outages which occurred during the selected Month and Year.
The System Availability section should also include a means of uploading one .csv containing Synthetic Tests results, for users with Write or Admin role. The .csv should be persisted as-is so that it can be downloaded later if necessary. The .csv is expected to have the following structure: Status, Timestamp (America/New_York TZ), Job Name, Duration (seconds), Session Visual Time (seconds), Error Type, Browser, Country, City; and it should be parsed and saved to a database table of identical structure, which should also include an Include binary that defaults to TRUE. After the .csv upload and save is completed, an Analyze Tests button should be enabled.
Clicking Analyze Tests should: set Total Transactions to the number of records in the .csv; set Include to FALSE for all records in the .csv which have Error Type “Normal” or “Test script crash”; set Include to FALSE for all records in the .csv which occurred during an Outage; set 5xx Outside of Outages to the count of records with Include TRUE and Error Type "5xx - Server Error"; set >5s Outside of Outages to the count of records with Include TRUE and Error Type "Timed out"; set Total Penalized Minutes to (Unplanned Outage Minutes + ((5xx Outside of Outages + >5s Outside of Outages) * 5)); set Actual SLA to (Minutes in Month - Total Penalized Minutes) / Minutes in Month, as a percent.
The End-to-End Response Time section should include sub-section Web Application; sub-section Web Service; and, sub-section MessageQueue. Each sub-section should be editable dependent upon whether they are enabled for the selected Client.
The sub-section Web Application should include Total Responses (number), >5s Responses (number), Contractual SLA (percent; read only for selected Client), and Actual SLA (percent).
The sub-section Web Service should include Total Responses (number), >2 Responses (number), Contractual SLA (percent; read only for selected Client), and Actual SLA (percent).
The sub-section MessageQueue should include Contractual SLA (percent; read only for selected Client), and Actual SLA (percent).
The Incidents section should provide a rich text input that allows users to input content.
Clicking Generate Report should generate a PDF for which a template will be described in future iterations, and into which data should be injected.