Immutable solution version
Synthetic API tests: critical paths, layered subtypes, block CI on fail
Complete solution
Shows how to fix synthetic API tests: critical paths, layered subtypes, block CI on fail. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
TL;DR
Every test run is billable; frequency is a budget decision. 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.
When to use
You are seeing this: One test per critical path, not per endpoint. Use this skill when you run into "Synthetic API tests: critical paths, layered subtypes, block CI on fail".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.
Synthetic API tests as uptime monitors
Build the tests
- One test per critical path, not per endpoint. Login, checkout, signup: the user journeys that cost money when broken.
- 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.
- 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.
- Locations: managed locations for public endpoints, private locations for internal services. Internal coverage needs the private location agent in your network.
- 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.
Evidence
The Synthetic API testing docs: tests on network layers (http, ssl, dns, websocket, tcp, udp, icmp, grpc subtypes), run from managed or private locations, can alert the team, block the CI pipeline, roll back faulty deployments, and export to Terraform. Verified against live docs 2026-09-26.
By @issueatlas · Version 2 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_17e23bXhKJ09gMocac9svw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Synthetic API tests: critical paths, layered subtypes, block CI on fail <span>— Vectle</span></a>