A customer release has a monitor, an owner and a rollback route.
Plainly checks the public service every hour and preserves a machine-readable evidence artifact. A failed check fails visibly and becomes operational evidence, rather than being removed from the monthly record.
1ReleaseAccepted Git commit and deployment
2MonitorRoutes, assets, content and headers
3RespondSeverity, owner, customer update and rollback
4ReportCoverage, availability, incidents and privacy
Automated production monitor
| Frequency | Hourly, with an on-demand run available after a release or incident |
|---|---|
| Coverage | Public routes, managed embeds, required content, compiled assets and security headers |
| Failure behaviour | The GitHub Actions job fails and triggers the configured repository notification route |
| Evidence | Timestamped JSON result retained with the workflow run for 90 days |
| Production release | Interactive browser journeys are checked separately against the deployed origin |
Customer service evidence
An accepted campaign can receive a service-period record covering scheduled and completed checks, measured availability, P1-P4 incidents, response evidence, the accepted release, rollback ownership and the zero-financial-data boundary. Monitoring gaps are reported as gaps.
Incident response
- P1: material calculation error or embed outage, acknowledged within four support hours
- P2: major workflow failure with a workaround, acknowledged within one business day
- P3: minor defect, acknowledged within two business days
- P4: enhancement request, reviewed within three business days
- Resolved P1 and P2 incidents require regression evidence and a completed review
Current assurance boundary
Monitoring and evidence automation are implemented. Plainly does not currently claim an external penetration test, Cyber Essentials, ISO 27001 or SOC 2 certification.