Exoplanet transit duration calculator
Know whether a whole transit fits in one night: a planet with a 3.5-day period orbiting at ten stellar radii crosses its star in 2.67827955606 hours, about 160.696773363 minutes, for a central passage. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Period
- 3.5
- Stellar radius
- 1
- Semi major axis
- 10
- Radius over a
- 0.1
- Duration hours
- 2.6782795561
- Duration days
- 0.1115949815
- Duration minutes
- 160.696773363
This exoplanet transit duration calculator estimates how long a planet takes to cross the disk of its host star for a central transit. You supply the orbital period in days, the stellar radius, and the orbital semi-major axis in matching length units; the engine applies the closed-form central-transit geometry T equals P over pi times arcsin of R-star over a, then reports the duration in hours, days, and minutes. The model assumes a circular orbit, impact parameter zero, and a negligible planet radius so the chord length is set by the stellar disk alone. Period and stellar radius must be strictly positive, and the stellar radius must stay smaller than the semi-major axis so the arcsin argument stays inside the open unit interval.
When a transit duration estimate helps
Students and instructors use a transit duration calculator when a problem set asks how long a planet with a three-day period around a solar-type star at ten stellar radii spends in transit, without forcing every learner to re-derive the arcsin chord from scratch. Amateur photometry planners convert catalogue periods and approximate a over R-star ratios into hour-scale windows so they know whether a full transit fits a single night.
Proposal writers and mission concept studies need a reproducible first-cut duration before they invest in full light-curve simulations with limb darkening and impact parameter. Failed validation does not consume balance. Keep period in days, keep R-star and a in one length unit, pin the cleaned hours in tests, and you get a stable central-transit duration for teaching, planning, and edge workers without standing up a photometry pipeline of your own.
What you can do with it
Homework and catalogue drills
Compute central-transit hours from textbook P, R★, and a values and check arcsin geometry before photometry labs.
Observing-night planning
Convert catalogue periods and a/R★ estimates into hour-scale transit windows for amateur or student telescope schedules.
FAQ
What happens if the semi-major axis is zero or negative?
A non-positive semi-major axis cannot define a closed transit geometry in this model and is not billed.
Do stellar radius and semi-major axis need the same units?
Yes. Only the ratio R★/a enters the formula, so both must share one length unit (for example both in solar radii or both in metres).
Does this include planet radius or impact parameter?
Inclined, grazing, or finite-Rp chords need a different tool or post-processing.
Why must the star's radius be smaller than the semi-major axis?
Because the formula needs the ratio of the two to stay below one. A star as large as the orbit would swallow the planet, so the transit geometry is undefined and the calculation is refused instead of returning a meaningless time.
Can I enter the orbital period in hours?
No. The period is taken in days, the unit most exoplanet catalogues use, and the result is then given in hours, days and minutes. Convert a period quoted in hours to days before you enter it.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/astro/transit-duration \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"period":3.5,"stellar_radius":1,"semi_major_axis":10}'const res = await fetch("https://api.kit.forhosting.com/astro/transit-duration", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"period": 3.5,
"stellar_radius": 1,
"semi_major_axis": 10
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/astro/transit-duration",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"period": 3.5,
"stellar_radius": 1,
"semi_major_axis": 10
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/astro/transit-duration", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"period":3.5,"stellar_radius":1,"semi_major_axis":10}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"period":3.5,"stellar_radius":1,"semi_major_axis":10}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/astro/transit-duration", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"period": 3.5,
"stellar_radius": 1,
"semi_major_axis": 10
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "astro.transit_duration",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Non-positive semi-major axis values fail with invalid_input because they cannot define a physical closed orbit for this formula.
What central transit duration means and what the response contains
Transit duration is the time a planet spends in front of its star as seen by a distant observer, measured from first to fourth contact when the full stellar chord is considered under the simple geometric model. For a circular orbit with a perfectly central transit the impact parameter is zero, the planet path goes through the centre of the stellar disk, and when the planet radius is neglected relative to the star the half-chord angle reduces to arcsin of R-star over a. Multiplying that angle by the orbital period over pi recovers the full duration in the same time unit as the period. This capability takes the period in days—the unit used by most exoplanet catalogues—and multiplies the day-scale duration by twenty-four so the primary field duration_hours matches how observers quote hot-Jupiter and super-Earth events. The response echoes the cleaned inputs period, stellar_radius, and semi_major_axis, reports radius_over_a for quick sanity checks, and includes duration_days and duration_minutes for worksheets that prefer those units. A small_angle_hours field shows the linear approximation obtained by replacing arcsin of x with x itself, which is accurate when the star is much smaller than the orbital separation. Method and formula strings document that the path is central_transit with circular_orbit_b0_rp_neglected so clients do not confuse this estimate with a full Mandel–Agol light-curve fit. There is no network lookup of stellar catalogues and no Monte Carlo draw of impact parameters: either the three numbers define a valid central transit and the engine returns deterministic floats, or the request fails with invalid_input naming the geometric or positivity rule that failed.
Input contract, units, and error behaviour
Solar radii for both R-star and a are common when you convert a from astronomical units using the solar radius in AU; metres work equally well if both fields are SI. POST a JSON body with three required finite numbers: period, the orbital period in days and strictly greater than zero; stellar_radius, the host-star radius in any length unit you choose; and semi_major_axis, the orbital semi-major axis in that same length unit. Each field may arrive as a JSON number or as a numeric string; missing fields, empty strings, NaN, and Infinity fail with invalid_input. The product rule that callers must remember is that semi_major_axis must be positive: zero and negative values are rejected with a clear message that a non-positive semi-major axis is non-physical for a closed transit geometry, and those failures are not billed. Period and stellar_radius must also be positive. Example: period equals three point five days, stellar_radius equals one, and semi_major_axis equals ten yields radius_over_a equals zero point one and a duration of roughly two point six eight hours, with the small-angle reference slightly shorter as expected. Pair the response with your own inclination or planet-radius corrections if your science case needs them; this endpoint answers only the central, circular, Rp-neglected rewrite.
Integration use cases
Deterministic test fixtures
Generate reproducible duration_hours for unit tests, proposal worksheets, and CI assertions on transit geometry code.
Technical questions
How do I calculate exoplanet transit duration for a central transit?
Send period P in days, stellar_radius R★, and semi_major_axis a in matching length units. The API returns T = (P/π)·arcsin(R★/a) scaled to hours, plus days and minutes.
What does the exoplanet transit duration calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.