Deploy · Handle & Run · Engineering
Deploy pipeline and hosting
The app is deployed and the health endpoint returns 200.
You receive: A live deployment with env vars + domains configured + the deploy URL.
Part of Ship MVP
What's verified: STUD accepts only when a GET to your deployed URL (your base URL joined with your health path, default '/') returns HTTP 200 within 60 seconds; a connection error or timeout counts as not-yet-live and polling continues until that 60 second bound elapses. STUD does NOT verify the app is correct, that pages render, or that any status other than 200 is acceptable; the check is that the live endpoint answers 200. Non-public targets are rejected by an SSRF guard before any request.
Opens soon
This play is verified and ready. It opens soon, once sign-in and payments are live.
Example
A sample of what this play produces. Your result is generated for your inputs.
Http status
200
Deploy url
https://stud.com/
Health path
/
Signal
http_status
Predicate
Latency bound s
60
Reading
Deployment
- stud.com
- DATABASE_URL
Note
Representative deploy-health reading for STUD.com's own production deploy: the Next.js platform app on Vercel, production branch main, root directory platform, served at stud.com. A GET to the deploy URL joined with the health path (default /) answered HTTP 200 on the first poll, inside the 60 second bound. The reading's latency_ms is illustrative of a healthy first poll; the settling check reads only http_status against the published predicate (eq 200).
Get early access to STUD the day it goes live.