Technical Maintenance Plan — Orderly Checkout API (Production Web Service)

System / service: Orderly Checkout API and its supporting database and job workers Owner / team: Platform Team (lead: Priya Nair) Version: v1.2 Last reviewed: 2 March 2026 Next review: 31 May 2026

---

1. Scope and systems

This plan covers the production deployment of the Orderly Checkout API, which processes online orders for roughly 40,000 active customers.

In scope

• Checkout API service (Node.js, three instances behind a load balancer)
• PostgreSQL primary plus one read replica
• Redis cache and the order-fulfilment job queue
• TLS certificates, DNS, and the cloud load balancer

Out of scope

• The third-party payment gateway (managed and monitored by the vendor)
• The marketing website (covered by a separate plan owned by the Web team)

2. Routine task schedule

Task	Frequency	Owner
Review dashboards and triage open alerts	Daily (business days)	On-call engineer
Apply routine OS and runtime patches	Monthly (window)	Sam Okoro
Restore the previous night's DB backup to staging and confirm row counts	Monthly	Sam Okoro
Review and update Node.js dependencies	Monthly	Priya Nair
Rotate API keys and database credentials	Quarterly	Priya Nair
Audit TLS certificate expiry across all domains	Quarterly	Sam Okoro
Capacity and cloud-cost review	Quarterly	Platform Team
Review and update this maintenance plan	Quarterly	Priya Nair

3. Monitoring and alerting

Signal	Threshold	Alert channel
API health check	Two consecutive failed checks (60s apart)	PagerDuty on-call
HTTP 5xx error rate	Above 2 percent of requests over 5 minutes	PagerDuty on-call
Checkout latency (p95)	Above 800 ms for 10 minutes	Slack #platform-alerts
Database disk usage	Above 80 percent	Slack #platform-alerts
Job queue backlog	More than 500 pending jobs for 15 minutes	Slack #platform-alerts
TLS certificate expiry	Fewer than 21 days remaining	Email + Jira ticket

4. Patching and update cadence

• Routine patches: OS and Node.js LTS patch releases are applied during the monthly maintenance window after passing the staging smoke tests.
• Dependency updates: Reviewed monthly. Patch and minor bumps are applied automatically once CI is green; major version bumps are scheduled as their own small project.
• Critical security patches: A critical, remotely-exploitable vulnerability is patched out of band within 48 hours of disclosure, approved by the team lead, and shipped via the standard deployment process.
• End-of-life tracking: Node.js 20 LTS is supported until April 2026; the upgrade to Node.js 22 is planned for the February window to stay ahead of end-of-life.

5. Backup verification

• What is backed up: PostgreSQL (primary), the Redis snapshot, and the encrypted secrets store.
• Frequency: Continuous WAL archiving plus a full daily snapshot retained for 30 days.
• Restore test: On the first Monday of each month, Sam restores the latest snapshot to the staging cluster and confirms order and customer row counts match production within tolerance, then records the result in the run log.
• Recovery targets: RPO 15 minutes, RTO 1 hour — defined in detail in the disaster recovery plan.

6. Maintenance windows and communication

• Standard window: Sundays 02:00–04:00 UTC, the lowest-traffic period for the service.
• Notice given: Planned work is announced 72 hours ahead in the customer status page and the internal #platform-announce channel.
• Status updates: Live updates are posted to the public status page during the window and a short summary is posted afterward.
• Emergency changes: Out-of-window work requires sign-off from the team lead and an immediate status-page note if any customer impact is expected.

7. Service levels and response targets

Severity	Definition	Response target	Resolution / update target
SEV-1	Checkout fully down or order data at risk	15 minutes	Updates every hour until resolved
SEV-2	Checkout degraded (slow, partial failures)	1 hour	Same business day
SEV-3	Minor or cosmetic issue, no customer impact	1 business day	Next maintenance window

Availability commitment: 99.9 percent monthly uptime for the checkout endpoint (about 43 minutes of allowed downtime per month).