Valheim Boss Attempt Debrief Worksheet

Why boss attempts need a debrief at all

A boss attempt compresses a lot of variables into a few minutes: which foods were active and how long they had left, whether everyone was rested, what weapons and armor were equipped, how the arena was prepared, who was carrying what, and how the group entered. When the fight goes wrong, memory keeps the most dramatic moment and drops the rest. Someone remembers the death, not the fact that two of three food timers were nearly empty when the altar was activated.

The debrief exists to recover the boring facts before they disappear. It is written within a few minutes of the attempt, while the tombstones are still on the arena floor, and it is written in the same shape every time. Two debriefs in the same shape can be compared. Two stories cannot.

The second purpose is to slow down the fix. A group that just lost a fight wants to change everything. The worksheet forces a ranking: list every candidate cause, then choose one primary change for the next attempt and park the rest. That is the same discipline the world modifier change log on this site applies to settings: one change, one dated entry, one observed outcome.

The six fields to record after every attempt

Keep the form short enough that someone will actually fill it in while the group is regrouping. Six fields are enough:

• Attempt ID and date — a simple counter such as BOSS-02 plus the real-world date. Do not reuse IDs across bosses; give each boss its own short prefix.
• Entry state — for each player: which foods were active, whether they were rested, and the main weapon, shield, and armor set. If someone does not remember, write UNKNOWN instead of guessing.
• Arena and route — how the group reached the altar, whether there was a portal or safe point nearby, and what the terrain or weather looked like at the start.
• Timeline in three lines — what happened first, what went wrong, and how the attempt ended. Three lines, not a paragraph.
• Candidate causes — every reasonable explanation anyone offers, each written as a short testable statement, for example "melee players ran out of stamina during the second phase."
• Next change — the one change the group commits to for the next attempt, plus the name of the player who owns making it happen.

Notice what is missing: there is no field for blame, and there is no field for a final verdict on the boss. A debrief that turns into an argument about who dodged late stops being written after the second attempt. Keep observations about play execution inside the candidate-cause list, phrased as conditions rather than people: "the tank was out of stamina" rather than "Tor messed up."

A worked example with a synthetic group

The table below is a synthetic example, not a recorded session. It shows how a three-player group might log two Bonemass attempts. The values are planning placeholders chosen to illustrate the format; they are not tested loadouts, damage results, or recommendations for a specific patch.

Look at what the group did between the two rows. The first debrief listed four plausible causes. The group could have changed all four. Instead, it chose one primary change, synchronized food and rest, and also built a portal because recovery was clearly broken. Strictly, that is two changes, and the debrief for BON-02 should say so honestly. The point is not purity. The point is that the record shows exactly what changed, so the outcome of the second attempt can be read against it.

The second row also carries an UNKNOWN forward. Nobody knows yet whether weapon choice mattered, because the group did not change it. That is a perfectly good result. It tells the group what it has not tested, which is more useful than a confident claim nobody can back up.

How to rank candidate causes without a long argument

Once the candidate list exists, sort it with three quick questions. You do not need a scoring system; a show of hands is enough.

• Did it happen before the fight started? Entry-state problems such as missing foods, no rested bonus, unrepaired gear, or a long walk through a hostile biome are cheap to fix and should usually be fixed first. They also contaminate every other observation: if half the group entered under-fed, you cannot learn much about weapon choice.
• Did more than one player report it? A cause that two or three people independently name is a better candidate than one that only the person who died first remembers.
• Can we change it without new materials? If a change needs another trip for ore or ingredients, park it unless the cheaper fixes have already been tried. A change you can make tonight produces information tonight.

Write the winner in the next-change field and copy the rest into a short "parked" line. Parked causes are not rejected; they are queued. If the next attempt fails for a reason unrelated to the primary change, the parked list is where the following change comes from.

Groups that like a tidy rule can use this one: after any wipe where at least one player entered without full food or rest, the next change is always entry state. It is not glamorous, but it removes the most common confounder before anyone spends materials on new gear.

Recovering cleanly before the next attempt

A debrief is also a recovery checklist. Before the next attempt, confirm that every tombstone has been retrieved or that a deliberate decision was made to leave it, that equipment is back on the right players, and that anyone who died has their food and rest restored. The death recovery guide covers the mechanics of retrieving gear without a second grave; the debrief only records that it happened.

Add one line to the worksheet for recovery state: "all gear recovered" or a list of what is still on the floor. If an attempt starts while someone is still missing armor, that fact belongs in the entry-state field of the next row, not in a vague memory that "Player B was squishy."

If the group uses a shared portal hub, check that the boss-area portal is labeled the way everyone expects before re-entering. The co-op portal hub label convention on this site describes a short naming pattern that keeps a rushed second attempt from sending someone into the wrong biome.

When the debrief says the problem is not the fight

Sometimes the honest conclusion is that the group is not ready for this boss yet. The candidate causes all point to gear tier, food tier, or a lack of materials that cannot be fixed tonight. That is a valid next change: "return to progression, revisit after upgrades." The progression order guide and the food loadout planner on this site help with that decision without inventing boss-specific numbers here.

Other times the evidence points away from play entirely: a disconnect at the start of the fight, a player who could not join, or behavior that looks like a bug rather than a mechanic. Record those in the timeline, mark the attempt as not comparable, and do not count it against the primary change. If something looks like a product issue, Iron Gate's support page is the channel for reports, and the same-site multiplayer bug report evidence article describes what to capture.

A one-page template to copy

Paste the following into a shared note before the session and duplicate it for each attempt:

• Attempt ID: boss prefix plus counter
• Date: real-world date
• Entry state: per player: foods, rested yes/no, weapon, shield, armor, or UNKNOWN
• Arena and route: approach, nearest portal or safe point, time of day
• Timeline: three lines: start, failure point, end
• Candidate causes: numbered testable statements
• Next change: one primary change plus owner
• Parked: remaining causes, untested
• Recovery state: all gear recovered, or what remains
• Comparable: yes, or no with a reason such as a disconnect

After a win, fill in one last row anyway. Note which change preceded the win and which parked causes were never tested. That short closing note is the most useful thing to read before the next boss, because it records how this particular group actually learns, not how a generic guide says it should.

Assumptions and limits

All example rows are synthetic and illustrate format only. Boss behavior, item names, and balance can change between builds; this article does not describe mechanics for a named patch and does not recommend specific loadouts. It assumes a cooperative group willing to spend two or three minutes writing after an attempt. It is not a modding guide, not a speedrun method, and not a substitute for Iron Gate support when something looks like a bug. No hands-on testing of a specific Valheim build was performed for this page.

Sources and method

• Iron Gate: Valheim FAQ — retrieved 2026-10-22
• Iron Gate: Valheim support — retrieved 2026-10-22

AI-assisted writing with automated source, calculation and editorial checks. No hands-on testing or professional certification is claimed. Check the stated assumptions before applying this guide.