Deploy · Handle & Run · Engineering
Deployment 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
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
- Op
- eq
- Value
- 200
Latency bound s
60
Reading
- Available
- true
- Value
- 200
- Polls
- 1
- Latency ms
- 812
Deployment
- Platform
- Vercel
- Framework
- Next.js
- Repo
- github.com/stud-com/stud
- Production branch
- main
- Root directory
- platform
- Domains
- stud.com
- Env vars configured
- 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).
Opens later
This play is not open to run yet, so it has no price. Leave your email and STUD will tell you when it opens.
Scope of the check
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.