Something is wrong in production. You caught it yourself, or someone pinged you, and now you're heads-down trying to work out what happened. The instinct — the one I had for years — is to stay quiet until you have something worth saying. Find the cause, confirm a fix, then report it in one clean message so you don't look like you're flailing in public.
On a Japanese dev team, that instinct quietly works against you. The complete report you're holding back for is the wrong first deliverable. What the team wants before anything else is a message that's fast and mostly empty: what broke, the fact that you're on it, and a promise that more is coming.
The word for that first message
There's a specific vocabulary for this, and it's worth knowing because you'll see it fly past in a channel the moment anything goes sideways.
The core word is 一報 (ichihō) — literally "one report," but in practice "the first heads-up." Sometimes you'll see the fuller 第一報 (dai-ichi-hō), "the first report," especially for something serious. What follows it is 続報 (zokuhō), the "follow-up report." So the shape of an incident, in Japanese, is one 一報 followed by as many 続報 as it takes.
The 一報 is not a summary of the problem. It's closer to a flare. Its whole job is to get the fact of the incident in front of people while you still don't understand it.
Why the half-empty message wins
This runs on the same logic as 報連相 (hōrensō), the reporting habit that governs a lot of Japanese team communication: a problem nobody has heard about is one nobody can help you with yet. During an incident that logic just gets sharper, because minutes compound. Every minute you spend going from "something's wrong" to "here is the full root cause" is a minute nobody else knows to check the dashboard, warn support, or notice they touched that service an hour ago.
A fast 一報 buys you the team's attention early, when it's cheapest to act on. Holding the message until it's complete does the opposite: it keeps the problem private for exactly the window when sharing it would have helped most. On the teams I've worked on here, the engineer who says "I don't know the cause yet, but I've told everyone" is read as more reliable, not less, than the one who went dark and came back an hour later with a tidy writeup.
What the first report actually says
Here's a first report you could drop into a channel the moment you notice something:
取り急ぎ一報です。本番でエラーが出ています。今、調査中（ちょうさちゅう）です。分かり次第（わかりしだい）、続報します。
"Quick heads-up: there's an error in production. I'm looking into it now, and I'll follow up as soon as I know more."
Four small pieces are doing the work.
取り急ぎ (toriisogi) means roughly "in haste" — it's the standard opener that signals "this is fast and incomplete, and that's on purpose." It gives you permission to send before you're sure. When you lead with 取り急ぎ, nobody expects the message to be complete.
一報です (ichihō desu) names the message for what it is: this is the first report, not the analysis.
調査中 (chōsa-chū) means "under investigation." The 中 (chū) on the end of a word is a useful little tag for "in progress" — 対応中 (taiō-chū), "handling it now," works the same way. It tells people you're actively on it without claiming you've solved anything.
分かり次第 (wakari-shidai) means "as soon as I know." X次第 is "the moment X happens," and here it sets the expectation that more is coming without promising a time you can't hit.
Notice what the message doesn't contain: a cause, a fix, an ETA, or an apology paragraph. Trying to include those is what makes people wait too long to send. The 一報 is allowed to be thin.
The detail goes in the follow-ups
Once the flare is up, the 続報 is where the real information lands, in whatever increments you actually have it:
続報です。原因（げんいん）が分かりました。〇〇の設定ミスでした。今から修正（しゅうせい）します。
"Update: found the cause. It was a misconfiguration in [X]. Fixing it now."
Then another when it's fixed, and usually a short close so people know they can stop watching:
復旧（ふっきゅう）しました。ご心配（しんぱい）おかけしました。
"It's recovered. Sorry for the worry."
That cadence — one thin 一報, then 続報 as facts arrive, then a clear "it's over" — is the whole pattern. The completeness you were tempted to front-load just gets spread across the follow-ups instead, arriving as you learn it rather than all at once at the end.
The shift that took me longest was trusting that an incomplete first message doesn't read as sloppy here. It reads as reliable. My own instinct still wants to go quiet and come back with the whole story tied up in a bow, and I have to talk myself out of it every time. The hard part was never writing the perfect incident summary. It was getting comfortable saying, out loud and early, "here's what I don't know yet."
If finding the right words for moments like this is the part that trips you up, I put together a course on exactly this kind of workplace Japanese for engineers: Japanese for Software Engineers (free with this coupon through Aug 21).
Top comments (0)