How Muhurat Is Calculated: How Apps Pick a Good Time

A muhurat search does not pick one perfect moment. It checks a whole date range at one place. It keeps only the stretches where every rule for the activity passes. Those stretches are the windows your app shows.

A muhurat is a good time to start something, chosen from the Hindu calendar. People also call it a shubh muhurat, which means an auspicious time. The rules come from the panchang, the Hindu calendar's five parts of each day. The main ones are the tithi (the lunar day), the nakshatra (the Moon's star group, one of 27) and the weekday. Each activity has its own list of allowed values. Some activities add more checks, such as the Sun's sign or the rising sign. Times that tradition avoids, such as rahu kaal (a daily stretch avoided for new starts), are listed inside each window.

Here is a real run. We asked our API for vehicle purchase times in New York for December 2026. It returned 9 windows, 144.5 hours in all. Rahu kaal fell inside 6 of them, and the API listed it beside each one. The same month returned 0 windows for starting a business. Below, we show why, and how to put both answers on a screen.

The parts a muhurat search checks

Each rule reads one part of the calendar at each moment. Here is what each part means, in plain words.

The speed matters. A window can only change when one of these parts changes. That is why most vehicle windows run for hours, while a rule on the lagna cuts a day into short pieces.

The calendar is read at the place of the event. The tithi and nakshatra change at the same instant everywhere. But sunrise, the weekday's start and rahu kaal follow the local sun. Our post on why rahu kaal changes by city shows how much that moves between US cities.

Five activities, five rule sets

Our API has one muhurat call: POST /v1/muhurta/{activity}. It supports exactly five activities. Any other name returns a 404 error that lists these five.

The rule sets really differ. A wedding ignores the weekday and the tithi. A vehicle purchase ignores the lagna. Only business cuts rahu kaal out of its windows. So the search has to know the activity before it can check a single minute.

Where the rules come from. For the first four activities, the rules were read off a widely used published calendar for New Delhi. Then they were checked window by window. For vehicles, our API matched all 88 published windows of 2026 within 3 minutes at both ends. It also matched all 112 windows of 2027, a year the rules were not read from. The business rules are the classical ones as written. They have not been measured against a calendar, and every answer says so with provenance.measured: false.

One month of vehicle windows in New York

We searched New York from Dec 1 to Dec 31, 2026, with no birth details. Times are Eastern Standard Time, the local time at the place.

The windows run from 80 minutes to a full day. Bhadra also falls inside 3 of them.

Take the first window, Thursday, Dec 3. At sunrise, 7:02 AM, the nakshatra was Hast and the tithi was the 10th of the dark half. Both are on the vehicle list, and so is Thursday. Hast gave way to Chitra at 11:53 PM, also on the list. The tithi turned to the 11th at 12:34 PM, also on the list. So no rule failed all day, and the window ran from sunrise to the next sunrise: 1,441 minutes.

The yoga that day was Ayushman, and the karana until 12:34 PM was Vishti. Neither is a vehicle rule, so neither cut the window. Each window in the answer lists the rules it passed, by ID. For this one they are MS-01 to MS-07 and MS-11. MS-01 is the nakshatra check, MS-02 the tithi and MS-03 the weekday.

What the API leaves for you to show

The API does not quietly drop times that some families avoid. Rahu kaal and bhadra come back under within_it, beside the window. The published vehicle calendar runs its windows straight through rahu kaal. So the API does the same, and lets your app decide how to show it.

Each answer also has a not_applied list. For vehicles it names rahu kaal, bhadra, panchaka, the yoga and the lagna, each with the reason it is not a cut. A not_computed list names three things the API does not work out yet: varjyam, amrit kaal and godhuli. That way a family astrologer can see what is in the answer and what is not.

Nothing is scored or ranked. If two windows pass, both come back, in date order. Do not label one of them "best". The API has no basis for that, and your users should not read one into it.

The same month for the other activities

We ran the same search for all five activities, New York, Dec 1 to Dec 31, 2026.

Why business found nothing. Three of its rules closed December. From Dec 1 to Dec 5, the lunar days were past the 5th of the dark half. In that half, business allows only the 1st, 2nd, 3rd and 5th. From Dec 6, Mercury was within 14° of the Sun, which counts as combust. From Dec 15, the Sun was in Sagittarius, a sign the business rules leave out.

A wider search, from Nov 12, 2026, to Mar 31, 2027, found 9 business windows. Seven fall on Nov 16, 25 and 26, and two on Mar 10, 2027. They last 22 to 152 minutes each. They are short because business keeps only a fixed rising sign: Taurus, Leo, Scorpio or Aquarius. For example, Nov 25 has a window from 6:54 AM to 8:39 AM, while Scorpio rises.

So an empty month is a real answer, not an error. Your screen needs a plan for it.

Make it personal with a birth date

Add birth to the request, and each window gains a for_you block. It checks two daily ratings from the person's birth Moon. Tara bala counts from the birth nakshatra to the day's nakshatra. Chandra bala counts from the birth Moon sign to the Moon's sign that day.

We sent John Doe, born Aug 15, 1990, at 10:30 AM in New York. Of the 9 vehicle windows, 4 suit him: Dec 13, Dec 14, Dec 23 and Dec 25. The other 5 stay in the list, marked suits_you: false. Each has a reason in why_not, such as "the transit Moon is in a weak house from your natal Moon".

For a wedding, add partner as well. We added Jane Doe, born Mar 22, 1992, at 2:45 PM in Chicago. Of the 7 wedding windows, only 1 suits both: Dec 12, from 7:10 AM to 4:58 PM. The answer marks it with suits_both: true.

The panchang and muhurat API page lists everything the calendar calls return, from the five daily parts to these muhurat windows. To see one day's panchang for your own city first, try the free panchang today tool.

The call

Send the date range, the place and, if you have it, the birth details. Here is the vehicle search above, for New York:

{
  "from": "2026-12-01",
  "to": "2026-12-31",
  "latitude": 40.7128,
  "longitude": -74.006,
  "timezone": "America/New_York"
}

It goes to POST /v1/muhurta/vehicle. Here is the first window from the answer, with the rule list shortened:

{
  "date": "2026-12-03",
  "weekday": "Thursday",
  "starts": "2026-12-03T07:02:44-05:00",
  "ends": "2026-12-04T07:03:42-05:00",
  "minutes": 1441,
  "nakshatras": ["Hast", "Chitra"],
  "tithis": ["Dashami", "Ekadashi"],
  "rules": [
    { "id": "MS-01", "status": "pass", "rule": "the nakshatra is one the activity allows", "seen": ["Hast", "Chitra"] }
  ],
  "within_it": {
    "rahu_kaal": { "starts": "2026-12-03T12:56:31-05:00", "ends": "2026-12-03T14:07:16-05:00" },
    "bhadra": [{ "starts": "2026-12-03T00:24:19-05:00", "ends": "2026-12-03T12:34:01-05:00" }]
  }
}

One search can cover up to 366 days. Send an IANA zone name such as America/New_York, and each window uses the offset in force on its own date. So a search across a daylight saving change stays right. Add lang=hi to get the nakshatra and tithi names in Hindi.

How to show the results

Show the place and its time. Every time in the answer carries the local offset of the place you sent. Print the city beside the times, so a user in Dallas does not read New York times as their own.

Show every window, then the times inside it. List the window first, then a line such as "Rahu kaal inside: 12:56 PM to 2:07 PM". If your users always skip rahu kaal, you can split the window in two. Either way, make the choice visible.

Explain each window in one line. The rules list already says why a window passed. A line such as "Hast nakshatra, 10th lunar day, Thursday" tells a user why the time was picked. Link the rule IDs to a details panel for the curious.

Plan the empty state. When count is 0, say that no window passes the rules in this range. Then offer a wider range. Do not fall back to a time that failed a rule.

Keep the personal answer gentle. Show "Suits you" next to a window, and the why_not reason beside one that does not. Do not hide a general window because it does not suit one person. The API does not hide it either.

Use calm words. A muhurat is a tradition's guidance on timing, not a promise about how things turn out. Words like "good time" and "times to avoid" are enough.

Every field in the muhurat answer, with its type, is in the muhurta API reference. For a store that offers booked pujas, see how muhurat fits a puja store site.

A muhurat search is a filter, not a forecast. Pick the activity, send the place and the dates, and show every window with the rules it passed. When a month comes back empty, say so plainly and offer the next range.