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.
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.
Proposed incident response
These are draft targets, not a live service guarantee. The pilot scope must name the actual support window, response targets and cover before launch. If the customer needs daytime cover that cannot be provided, the campaign does not launch.
- 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
Monitoring and evidence automation are implemented. Plainly does not currently claim an external penetration test, Cyber Essentials, ISO 27001 or SOC 2 certification.