Bring Down, Take Down, and Go Down

By the end of this lesson, you will be able to...

• distinguish a service becoming unavailable from an actor causing or deliberately scheduling that state;

• choose bring down, take down, or go down from the evidence and the intended agency;

• write an availability update that names the object, the actor when known, and the difference between an outage and a planned removal.

Idea in one sentence: Availability language changes the investigation when it shows whether a system acted, an operator acted, or the service simply became unavailable.

Core Insight

The previous lesson described rolling a release out and rolling it back. This lesson asks what the reader should say about availability when the service is no longer serving requests.

Three updates can describe the same visible result — the API is unavailable — but they assign different information:

The bad configuration brought the API down.
We took the API down for maintenance.
The API went down at 02:14 UTC.

The first sentence names a cause that changed the service state. The second names an intentional operator action. The third reports the state without claiming who caused it. Choosing the wrong form can misdirect an incident review or make planned maintenance sound like an unexplained failure.

The Small Situation

An API team has just rolled out a parser fix to 25% of traffic. During the window, three availability events are possible:

The naive incident note is:

The API was taken down by the dependency, so we brought it down during maintenance.

The sentence mixes an intentional action, an external cause, and an unexplained state. It also makes the dependency sound like an operator. Before choosing a phrasal verb, ask:

1. Is the service unavailable, or did someone deliberately remove it?
2. What or who caused the state transition?
3. Is the cause confirmed, suspected, or still unknown?

The Naive Idea: “Down” Is the Whole Meaning

It is easy to treat bring down, take down, and go down as three versions of “become unavailable.” That loses agency.

Compare the subjects and objects:

The deployment brought the API down.
The team took the API down.
The API went down.

Bring down and take down are transitive: something or someone acts on an object. Go down is intransitive: the service itself is the subject and no object follows it.

The technical distinction is not a promise that the first sentence identifies the ultimate root cause. A deployment can bring a service down because it installed a bad configuration; the incident still needs evidence. The grammar tells the reader where the writer is placing agency, not whether the investigation is complete.

The Mechanism: State, Actor, and Intent

Plain meaning:

Use the verb that matches the information you have:

Technical name:

Bring down and take down are causative transitive phrasal verbs in this operational use. Go down is an intransitive state-change phrasal verb. The particle down points to reduced availability, but the verb determines how the sentence presents the cause or agency.

Use Bring Down for a Causing Event

Bring down says that a person, change, dependency, or object caused another system to become unavailable:

The invalid certificate brought the API down.
The deploy brought two workers down.

The object comes after the phrasal verb or between the verb and particle:

The invalid certificate brought the API down.
The invalid certificate brought down the API.

With a pronoun, put it between the verb and particle:

The invalid certificate brought it down.

Not:

The invalid certificate brought down it.

Use a careful subject. A deployment may be the immediate event, but it may not be the deeper cause:

The configuration reload brought the canary down; we are checking whether the certificate caused the failure.

This sentence separates observed agency from a still-open hypothesis.

Use Take Down for an Intentional Removal

Take down says that an actor deliberately removes a service, endpoint, page, or environment from availability:

We took the endpoint down for planned maintenance.
The operator took the canary down before the migration.

The action may be a safety measure and does not imply failure:

We took the write path down before changing the schema.

The object forms are:

We took the endpoint down.
We took down the endpoint.
We took it down.

Again, a pronoun sits between the verb and particle. Name the reason or change ticket if the reader could confuse planned work with an outage:

We took the endpoint down for maintenance under change CHG-241.

Use Go Down for the Observed State

Go down reports that a service becomes unavailable without assigning an actor in the sentence:

The API went down at 02:14 UTC.
The dependency goes down when its database reaches the connection limit.

There is no object after go down:

The API went down.

Not:

The API went down the endpoint.

If later evidence identifies a cause, add a separate causal clause:

The API went down at 02:14 UTC because the dependency stopped accepting connections.

Starting with go down can be the honest choice during the first minutes of an incident. It reports the symptom without pretending that the root cause is already known.

A Worked Availability Trace

Start with the deployment timeline:

02:10: parser fix rolls out to the canary
02:14: health checks fail
02:15: on-call sees certificate reload errors
02:18: team disables the canary and serves traffic from the old release
03:00: planned maintenance begins on a separate endpoint

Input: the first observation

The canary went down at 02:14 UTC.

At this point, the state is known and the cause is not confirmed. Went down avoids an unsupported accusation.

Transition: evidence identifies an immediate cause

The certificate reload brought the canary down.

Now the subject names the event that caused the observed failure. If the evidence is preliminary, qualify it:

The certificate reload appears to have brought the canary down.

Decision: an intentional safety action

We took the canary down and rolled the release back to the previous version.

The team deliberately removes the canary, then uses the rollback action from lesson 009. These are separate actions with separate objects.

Parallel planned work

At 03:00, we will take the admin endpoint down for planned maintenance.

The future action is intentional. It should not be reported as the endpoint went down, which would make the maintenance sound accidental.

The complete incident note is:

The canary went down at 02:14 UTC. The certificate reload appears to have brought it down. We took the canary down and rolled the release back to the previous version. At 03:00, we will take the admin endpoint down for planned maintenance.

The input is the observed failure. The transition is the evidence-backed cause. The decision is the deliberate removal and rollback. The final sentence distinguishes a planned future action from the incident. The naive failure contrast is the original sentence that assigned every state change to the wrong actor.

Where the Forms Can Overlap

The outcome can be identical while the agency differs:

The provider brought the service down during an emergency.
We took the service down to protect user data.
The service went down during the network event.

All three may end with no available requests. The first points to an external cause, the second to an intentional operator decision, and the third to an observation. Choose based on what the reader must know, not on which phrase sounds more dramatic.

Bring down can also describe a deliberate action when the actor causes the state:

We brought the test cluster down after the experiment.

In an availability incident, take down often foregrounds deliberate removal, while bring down foregrounds the event that caused the state. If the distinction matters, include the reason:

We took the cluster down deliberately after the test; the failed certificate brought the canary down unexpectedly.

Common Confusions

Confusion: go down names the root cause

Why it is tempting:

The sentence sounds complete and may be the first line in an incident channel.

Better model:

Go down names the state change. Add a separate cause only when evidence supports it:

The API went down; the dependency is the current leading suspect.

Confusion: take down always means an outage

Why it is tempting:

The result is that users cannot access the object.

Better model:

Take down can describe planned maintenance or a safety action. Add the intent:

We took the write endpoint down before the schema change.

Confusion: bring down and roll back are the same action

Why it is tempting:

Both can appear after a bad release.

Better model:

Bring down describes causing unavailability. Roll back describes returning a release or configuration to an earlier version. A rollback may bring a canary down first, but the verbs describe different transitions:

The bad config brought the canary down, so we rolled the release back.

Confusion: the subject can be omitted safely

Why it is tempting:

Incident shorthand often says “was taken down” or “went down” without context.

Better model:

Name the subject and actor when ownership or intent matters:

The on-call engineer took the admin endpoint down for maintenance.

Check Your Understanding

Check: The cause is not known yet; only the outage time is confirmed. Which sentence is safest?

1. The API went down at 02:14 UTC.
2. The dependency brought the API down at 02:14 UTC.

Think first, then reveal.

Answer: Sentence 1. It reports the observed state without assigning an unverified cause.

Check: The operator intentionally disables an endpoint before a schema change. Which sentence shows that intent?

1. The endpoint went down before the schema change.
2. We took the endpoint down before the schema change.

Think first, then reveal.

Answer: Sentence 2. The subject we and took ... down make the planned action visible.

Check: A bad configuration causes a canary to become unavailable, and the team then returns to the previous release. Which sentence keeps the actions distinct?

1. The configuration brought the canary down, so we rolled the release back.
2. The configuration rolled the canary back, so the release went down.

Think first, then reveal.

Answer: Sentence 1. Brought down describes the availability failure; rolled back describes the version reversal.

Transfer Challenge: Repair the Availability Update

A teammate writes:

The API was taken down by the dependency at 02:14, and we went down the admin endpoint for maintenance. Then we rolled back the outage.

Rewrite the note in four sentences. Keep these facts:

• the API became unavailable at 02:14;
• the dependency is a suspected cause, not yet confirmed;
• the team deliberately removed the admin endpoint for maintenance;
• the canary release was returned to the previous version.

Your answer should:

• use go down for the observed outage;
• use bring down only with evidence or a qualified hypothesis;
• use take down for the planned operator action;
• use roll back for the release reversal.

One possible answer:

The API went down at 02:14 UTC. The dependency may have brought it down; we are checking connection errors now. We took the admin endpoint down for planned maintenance. We rolled the canary release back to the previous version.

The answer separates observation, hypothesis, intentional removal, and version reversal. That separation gives the incident owner four clear things to verify.

Daily Practice Lines

• The API went down during the deploy; the cause is still under investigation.
• The bad configuration brought the canary down, so we rolled the release back.
• We took the admin endpoint down for planned maintenance.

The second line reuses roll back from lesson 009 and the causal direction from earlier lessons. Replace API with worker pool or queue, but keep the difference between state, cause, and intent.

What This Changes

Availability updates now carry a small agency model. Go down is a careful first report. Bring down connects a confirmed or qualified cause to the state change. Take down records an intentional operator decision. This vocabulary helps a reviewer separate symptom, cause, mitigation, and planned maintenance without adding a long incident narrative.

The next lesson moves from availability to environment lifecycle with set up, spin up, tear down, and clean up. It will apply the same discipline to resources: what an operator creates, what a platform starts, what is removed, and what residue remains.

Trade-offs and Limits

The trade-off is between concise status language and explicit ownership. The API went down is fast and honest when the cause is unknown, but it leaves the actor open. The deployment brought the API down gives a useful causal hypothesis, but it can overstate the evidence if the dependency has not been ruled out. We took the API down makes intent clear, but only when an operator actually made that decision.

The verbs also do not describe the full recovery. Bringing a service down does not explain why it failed, taking it down does not prove that maintenance was safe, and going down does not identify the repair. Add timestamps, signals, owner, and next action when the note is operationally important.

Object placement is another boundary. We took the endpoint down and We took down the endpoint work with a noun, while We took it down is the natural pronoun form. If the reader cannot tell what became unavailable or who changed it, the sentence needs a named object or actor rather than a stronger adverb.

Resources

• [ARTICLE] Cambridge Dictionary Grammar - Review transitive and intransitive phrasal verbs, separable objects, and pronoun placement.
• [ARTICLE] Microsoft Writing Style Guide - Review incident wording that names actors, observed states, intent, and evidence without overclaiming.

Key Takeaways

• Use go down to report that a service became unavailable without assigning a cause.
• Use bring down when an event or object causes another service to become unavailable.
• Use take down when an actor deliberately removes a service or endpoint, often for maintenance or safety.
• Bring down and take down take an object; go down does not.
• Separate availability state, suspected cause, intentional action, and rollback so the update preserves ownership and evidence.