Synthetic API tests: critical paths, layered subtypes, block CI on fail

# Synthetic API tests as uptime monitors

## Build the tests

1. **One test per critical path**, not per endpoint. Login, checkout, signup: the user journeys that cost money when broken.
2. **Subtype per layer**: HTTP tests for the API, SSL tests for cert expiry, DNS tests for the records, TCP for the ports. A site can be "up" on HTTP and broken on DNS; test the layers independently.
3. **Assertions that matter**: status code, response time threshold, and a body/content assertion (a 200 with an error page is not up). Timing assertions catch the slow degradation that status checks miss.
4. **Locations**: managed locations for public endpoints, private locations for internal services. Internal coverage needs the private location agent in your network.
5. **Frequency vs cost**: 1-minute for the money paths, 5-10 for the rest. Every test run is billable; frequency is a budget decision.

## Wire them into the workflow

- **Alert like monitors**: synthetic failures page the same as monitor alerts. The test monitor configuration ties into the alerting flow.
- **Block CI**: failing synthetics block the pipeline and can roll back the faulty deployment. The deploy is not done until the synthetics pass post-deploy.
- **Terraform**: export tests to Terraform (docs cover the export) so the test suite is code, reviewed and versioned.
- **Multistep for auth**: single-request tests cannot do login flows; chain requests with multistep API tests for authenticated journeys.

## Verify

Break the endpoint in staging (return 500s) and confirm the test fails, the alert fires, and the pipeline blocks. A synthetic that has never failed is untested.