Egg hatch time, incubator temperature and the setting everyone misreads

There is no hatch time in hours anywhere in Palworld's data, and that is not an extraction failure — it is how the system is built. Hatching is a work model: an egg needs an amount of work, and an incubator supplies work per second. The game ships every rate, every multiplier and every divisor in that calculation, and it never ships the one number a duration would need. So this page gives you the exact ratios instead, and they are worth more than a wrong hour count.

Verified against the shipped dedicated-server data for patch 1.0.3.

Why every hatch time you have read in hours is wrong

Hatch time is the product of four independent factors. Three of them are fully serialized and we print them below. The fourth — how much work an egg actually needs — is not.

That last gap is precise rather than vague. The server binary contains the property name HatchingWorkAmount, and no extracted asset gives it a value. The only property in the game with "HatchingTime" in its name is PalEggDefaultHatchingTime, and that is the difficulty multiplier, not a duration. There is no field anywhere for a base hatch length in seconds, minutes or hours.

So the two figures in widest circulation both fail, for different reasons:

• "A Huge egg takes 72 hours." The 72 is real, but it belongs to a different field in the same difficulty-preset row: AutoResetGuildTimeNoOnlinePlayers, the guild auto-reset timer. It has nothing to do with eggs.
• "Normal 5 minutes, Large 10, Huge 15." Every concrete duration table we could trace predates the 1.0 release. Since 1.0 ships a five-bracket rarity array and a nine-entry temperature lookup, pre-1.0 minutes cannot be carried forward, and the 1 : 2 : 3 shape that table implies is contradicted by the divisors below.

A name with no value is not a number. How we decide what to publish →

Factor 1 — rarity, and why the ratio is 1 : 6 : 12

PalEggRankInfoArray in BP_PalGameSetting has five brackets, not the three or four usually published. Each bracket carries an EggScale (the visual size of the egg) and a HatchingSpeedDivisionRate — a divisor on hatch time, so a bigger divisor means a faster hatch. There are only three distinct divisor values across the five brackets: 12.0, 12.0, 2.0, 2.0, 1.0.

Turn those into times and the real shape appears: 1 : 6 : 12. Not 1 : 2 : 3. The two lowest brackets share a divisor and the two middle brackets share a divisor, which is exactly the detail that collapsing five brackets into three sizes destroys. The full table with each bracket's EggScale is on the cakes and Breeding Farm guide — it is generated from the game data on every build, so we link it rather than retype it.

One thing you can act on without any further inference: the size you can see and the speed you cannot are read from the same row. A visibly bigger egg is a rarer Pal, and it is never a faster one, because EggScale and the divisor live side by side in the same bracket — as the scale rises across the five brackets the divisor only ever falls or holds.

Factor 2 — temperature, the whole nine-step table

This is the lever worth actually optimising. PalEggHatchingSpeedRateByTemperature is a nine-entry lookup keyed on the absolute difference between the incubator's temperature band and the egg's preferred band. Absolute, because the basic incubator blueprint's own GetTemperatureDiff function declares an Abs_Int local — the single one in the whole export — so the difference is passed through an absolute-value call before anything else uses it, and being too hot and being too cold by the same amount cost exactly the same.

Three corrections fall straight out of that table.

• "Comfy doubles the hatch speed" is exactly right. Rate 2.0 at an exact match. This is the one widely repeated temperature claim that survives contact with the data.
• A cold egg does not stall. There is no zero anywhere in the table and no entry below 0.75. The standard reply to "my egg says it seems cold" — that it has stopped, or that it will take forever — is wrong. It is running at three-quarters speed.
• The mismatch penalty is not 2× to 5× longer. Dividing by 0.75 makes a badly sited egg about 33% slower, not two to five times slower. And the penalty floors: four bands out is no worse than eight bands out.

The neutral zone is the part nobody publishes. Two and three bands away are exactly 1.0 — no penalty at all. Combined with the floor, the entire spread from perfectly sited to worst case is 2.0 down to 0.75, a factor of about 2.67. That bound matters when you are troubleshooting: temperature alone can never explain an egg that appears to have made no progress.

What the incubator's message is telling you

The game ships exactly eight hatch-state strings in its UI text table, keyed COMMON_WORK_HATCH_STATE_*, and they are symmetric around comfortable:

Five severity levels, with the outer three doubled by direction. That is the same five-step shape as the rate table's distinct positions (0, 1, 2, 3, and 4-and-beyond), which makes a one-to-one correspondence look very likely — but the record that joins a message to a lookup key is not in any asset we can read, so we are not going to publish a message-to-percentage mapping. What holds regardless of how they line up is the important part: no message in that ladder corresponds to a stall, because no entry in the rate table is below 0.75.

Factor 3 — the incubator you built

Every incubator carries an explicit AutoWorkAmountBySec on its egg-hatching component, and the values differ per building. Display names below are the game's own, from its English map-object name table, so nothing here is a guessed product name.

Points to take from that table, and one refusal.

• Every incubator is Ancient technology. All five rows in DT_TechnologyRecipeUnlock carry IsBossTechnology = true, so they cost Ancient Technology Points, not ordinary ones — and four of the five also gate on a specific tower boss. Heaters and coolers, by contrast, are ordinary points. The cheap fix for hatch speed is the temperature, not the building.
• The Large Incubator is not faster than the basic one. Both sit at 1.0. Only the two electric models raise the rate at all.
• We will not convert these into a "% faster" figure. The 1200.0 on the Ancient Hatchery is the warning: if AutoWorkAmountBySec were a plain speed multiplier, that building would hatch anything instantly. We have not established that hatch progress is the only consumer of that work channel, nor how it composes with the rarity divisor and the temperature rate. The field values are solid; a percentage derived from them would not be.
• The tower-boss column holds the game's own enum values. We print GrassBoss and VikingBoss rather than matching them to in-game tower titles, because that join is not in the data we extracted — see the tower bosses guide for who is where.
• Incubators cost sanity; the Breeding Farm does not. All four plain incubators carry AffectSanityValue = -0.11 with one worker slot, against 0.00 at the Breeding Farm. The Ancient Hatchery is the exception among hatching buildings: 0.00, two worker slots, and bPlayerWorkable = false — the same profile as the farm.
• We are not publishing an egg capacity for any of them, and the ten-egg figure for the Large Incubator has no field behind it. No blueprint carries a capacity property. What they do carry is egg child-actor components: one on the basic Egg Incubator, three on each of the two Large models — with three matching completion effects, which is plainly where "three at a time" comes from — zero on the Breeding Farm, and, oddly, one on the Ancient Hatchery. Because that count does not rise with the building's tier, we read those components as visual slots rather than as a proven capacity, and we are not converting them into a number.

The electric incubator and its own temperature

The claim that an Electric Egg Incubator manages its own temperature has a real structural hook, and we can show you exactly how far it goes.

BP_BuildObject_ElectricHatchingPalEgg derives from the basic incubator and overrides GetCurrentTemperature. The override's local variables are the tell: alongside a validity check they include CallFunc_IsWorkable_ReturnValue, CallFunc_GetCurrentTemperature_CurrentTemperature (the parent's ambient reading) and CallFunc_GetHatchingTemperature_Temperature (the egg's own target). A compiled blueprint function carries one such local per call it makes, so this function does call both the ambient reading and the egg's target, and checks whether the machine is working while it does.

What it then returns, we cannot see. The function body is Kismet bytecode and these exports contain none, so the honest statement is that the electric incubator is structurally capable of substituting the egg's target for the ambient reading and we cannot confirm from the files that it does. Do not treat "electric incubators ignore temperature" as established, and do not treat it as refuted either.

The same caution applies in the other direction to the multi-egg models. BP_BuildObject_MultiHatchingPalEgg and BP_BuildObject_MultiElectricHatchingPalEgg descend directly from the native PalBuildObject class rather than from the temperature-aware basic incubator, and contain zero references to the temperature component. That is a genuine structural difference — but the electric single-egg incubator, which certainly is temperature-aware through its parent, also shows zero such references in its own export. Absence in a blueprint export is not absence of behaviour. We have not been able to confirm whether temperature affects the Large Incubator, and we are not going to state that it does not.

Factor 4 — the world setting that is not a number of hours

PalEggDefaultHatchingTime is a multiplier, and its default is 1.0. Here is the whole case, and you can check the last line yourself.

• It is not hours. Values of 0.5 and 2.0 are meaningless as durations and obvious as a factor, and the field sits in a row alongside exactly 24 other rates that all read 1.0 on Normal — ExpRate at 1.3 / 1.0 / 0.8 / 0.8, PalCaptureRate, CollectionDropRate, and so on.
• Its default is not 72. The 72 in that same preset row is AutoResetGuildTimeNoOnlinePlayers, identical across all four presets.
• The shipped configuration file says so outright. DefaultPalWorldSettings.ini, distributed with the dedicated server, contains the line PalEggDefaultHatchingTime=1.000000. If a hosting panel tells you the default is a number of hours, that line is the counter-example.
• Hardcore is not slower than Hard. Both are 2.0. The assumption that each difficulty step is harsher does not hold for this field.
• "Set it to 0 for instant hatching" is unverifiable. No shipped preset uses 0 and no clamp on the value is stored anywhere we can read, so we cannot tell you what the game does with it. Why we leave that blank →

A small tell that these are real files: the sibling field in that same table is misspelled Diffculty in the shipped data, and one of the hatch-temperature delegates in the binary is named HatchTemperaturDelegate.

Heaters and coolers, per source

Each heat source is a BP_HeatSourceSphereComponent carrying a heat level and a sphere radius. All four are in the ordinary technology tree, not the Ancient one.

Three things worth knowing here.

• Heat sources are not weaker at night. The game models the possibility — the field is genuinely split into HeatLevel_DayTime and HeatLevel_NightTime — and then sets both values identically on all four buildings. A heater is exactly as strong at 3am as at noon.
• The electric versions double the radius, which is eight times the volume. 3,000 against 1,500 on a sphere. We print the raw radius rather than converting it to metres, because that conversion depends on a unit convention we have not verified.
• "One Electric Heater equals five ordinary heaters" is wrong under either rule. If overlapping sources take the highest value, the Electric Heater's 2 beats any number of 1s outright and five ordinary heaters are pointless. If they add, five ordinary heaters give 5 against the Electric's 2 and win comfortably. There is no reading of the data on which the two are equivalent.

Element does not change hatch speed

Egg items carry nothing for a per-element timing rule to key on. Across the 55 live egg rows in DT_ItemDataTable — five sizes for each of the nine element families plus the World Tree and mutated eggs — there is no time field, no temperature field and no day/night field. (There is a 56th egg row, an unnumbered PalEgg_MutationPal duplicate of the Huge Mutated Egg, but it carries bLegalInGame = false and is a development leftover, so we do not count it.) The ElementType column on a Dark Egg is even set to None: the element lives in the row name, the icon and the visual blueprint, not in a gameplay value.

So "Dark eggs take twice as long at night" has no mechanism, and the doubling in it is the comfort bonus misattributed. But the observation behind it is real and worth restating correctly: night lowers ambient temperature, so an incubator that only just reaches a comfortable band during the day can drop out of it after dark. That slows any egg, of any element. If your hatch times feel inconsistent between day and night, the fix is more heat, not a different egg.

The only two Pal bonuses that raise hatching speed

Setting the building and the temperature aside, we enumerated every row in the game's passive table carrying the PalEggHatchingSpeed effect type. There are six such rows and they belong to exactly two sources — five condensation tiers of one partner skill, and one passive:

Those are the field values as stored. How they compose with the temperature rate, the rarity divisor and the world-preset multiplier is not something we have verified in game, so treat them as ranked options rather than as additive percentages. Note also that Dynamoff's bonus does nothing at all until the saddle is crafted — the game's own name for a pal-gear row is a "skill unlock", which is exactly why an uncrafted saddle silently disables the partner skill.

The Ancient Hatchery, and what its numbers actually say

The endgame facility that breeds and hatches in one object is internally MultiElectricHatchingPalEggWithBreed, and its display name in the game's own English text table is Ancient Hatchery. Its numbers are extreme in two places:

• BreedRequiredRealTime = 10.0, against 300.0 on the wooden Breeding Farm. Five minutes of real time per egg becomes ten seconds. This is the one place where the building's advantage is stated in a unit we can read without inference.
• AutoWorkAmountBySec = 1200.0, against 1.0 on the basic incubator — and its power draw is also 1200. We are not turning that into a hatch time, for the reason given above.

The cost, as raw field values: RequiredBuildWorkAmount of 1,000,000 — 200 times any other incubator — built from 100 Paloxite Ingot, 50 AI Core, 30 Ancient Civilization Parts and 20 Ancient Civilization Core, unlocked for 8 Ancient Technology Points at level 76 with no tower-boss requirement. We publish the build-work field rather than converting it to the number shown in the UI, because the conversion convention that holds for item recipes has not been confirmed for build objects.

Two claims about it we will not repeat: the specific seven-second hatch figure, which no field supports; and the idea that partner-skill bonuses do not apply to it, since the hatching-speed effects target build objects with no structure-type filter in their data.

Does it run while you are offline

The data settles the unit and not the behaviour. The incubator accumulates work per second and the farm counts down a field explicitly named BreedRequiredRealTime. Both are wall-clock, so in-game day length, DayTimeSpeedRate and NightTimeSpeedRate do not change hatch or breeding progress.

Whether that clock advances with nobody logged in depends on whether the world is running — a dedicated server versus a hosted co-op session versus a single-player save — and no game asset states it. We are not going to guess mode by mode. The save files and settings guide covers where those options live.

A hatchery layout that follows from the numbers

• Build your passive-carrier lines out of low-rarity Pals. The rarity divisor is worth up to 12× and no building or passive comes close to it. Chase a passive on a common species, then move it up.
• Spend ordinary technology points on temperature before spending Ancient points on incubators. A Heater is 2 ordinary technology points at level 17 and an exact temperature match is a flat 2×; the next incubator step up is 5 Ancient points and a tower boss for a rate that goes from 1.0 to 1.5.
• Aim for the exact band, not for maximum heat. Overshooting costs you: past three bands out you are at 0.75 whichever direction you went, and the aggregation rule for extra heat sources is not something anyone can currently verify.
• Put a Hot Spring near the incubators, not near the farm. Every plain incubator drains sanity at -0.11 and the Breeding Farm drains none at all, so the comfort structures belong on the hatching side of the base.
• Build more incubators than farms. A Breeding Farm completes a cycle every BreedRequiredRealTime of 300 seconds — real seconds, not in-game ones — while a basic incubator accumulates work at 1.0 per second with a single worker slot. The technology is a one-off unlock — a single Ancient point at level 10 — and every plain incubator after that is 5,000 build work, so incubators are the cheap half of the operation to duplicate.

What to do next

• Plan the pairings with the breeding calculator and the breeding guide.
• Get the cake supply chain and the farm itself running — see cakes and the Breeding Farm, which also carries the full egg-tier table.
• Read how we verify things if you want to know why this page has ratios everywhere and not one figure in hours.

Frequently asked questions