From 140cef526679650610f87b8db0f89e8fa2c904cb Mon Sep 17 00:00:00 2001
From: Min RK <benjaminrk@gmail.com>
Date: Mon, 30 May 2022 15:55:37 +0200
Subject: [PATCH] run pre-commit autoformatters

---
 .github/ISSUE_TEMPLATE/repo_check.md          |   1 -
 .github/ISSUE_TEMPLATE/request_resources.yml  |   1 -
 .github/workflows/cd.yml                      |   5 +-
 .github/workflows/watch-dependencies.yaml     |   1 -
 README.md                                     |  24 +--
 WISDOM.md                                     |   4 +-
 config/ovh.yaml                               |  14 +-
 config/prod.yaml                              |   1 -
 config/turing.yaml                            |   5 +-
 deploy.py                                     | 118 ++++++-----
 docs/source/components/cloud.md               |  15 +-
 docs/source/components/dashboards.md          |   1 +
 docs/source/components/ingress.md             |  32 +--
 docs/source/components/metrics.md             |  37 ++--
 docs/source/conf.py                           |  10 +-
 docs/source/deployment/how.md                 | 183 +++++++++---------
 docs/source/deployment/prereqs.md             |   6 +-
 docs/source/deployment/what.md                |  78 ++++----
 .../getting_started/production_environment.md |  24 +--
 .../source/incident-reports/2017-09-29-504.md |   6 +-
 .../incident-reports/2017-11-30-oom-proxy.md  |  31 ++-
 .../2018-01-04-failed-staging-deploy.md       |   7 +-
 .../2018-01-17-ubuntu-upgrade.md              |  30 +--
 .../incident-reports/2018-01-18-reddit-hug.md |   5 +-
 .../2018-01-18-ssl-outdated.md                |   4 +-
 .../2018-02-12-launch-fail.md                 |   9 +-
 .../2018-02-20-jupyterlab-announcement.md     |  46 ++---
 .../incident-reports/2018-02-22-nginx-down.md |   1 -
 .../2018-03-13-PVC-hub-locked.md              |  40 ++--
 .../2018-03-26-no-space-left.md               |   2 -
 .../2018-03-31-server-start-fail.md           |  25 ++-
 .../incident-reports/2018-04-18-cull-flood.md |  19 +-
 .../2018-07-08-podsnips-aplenty.md            |   3 +-
 ...018-07-30-jupyterlab-build-cpu-saturate.md |  10 +-
 .../incident-reports/2019-02-20-no-logs.md    |  19 +-
 .../2020-07-09-simultaneous-launches-scipy.md |  16 +-
 .../2022-01-27-prime-version.md               |   6 -
 .../operation_guide/command_snippets.md       |  76 ++++----
 .../source/operation_guide/common_problems.md |  46 ++---
 docs/source/operation_guide/grafana_plots.md  |  16 +-
 images/analytics-publisher/archiver.py        | 104 +++++-----
 images/analytics-publisher/cloudcosts.py      |  84 ++++----
 images/analytics-publisher/indexer.py         |  70 +++----
 images/analytics-publisher/run.py             |  38 ++--
 images/federation-redirect/app.py             |  15 +-
 images/federation-redirect/test_rendezvous.py |   2 +-
 images/tc-init/README.md                      |  24 +--
 images/tc-init/example.yml                    |  28 +--
 .../etc/jupyter/jupyter_notebook_config.py    |  34 ++--
 mybinder/values.yaml                          |  35 ++--
 post-grafana-annotation.py                    |  44 ++---
 scripts/datacenters.py                        |   3 +-
 scripts/delete-pods.py                        |  65 +++++--
 scripts/drain-user-node                       |   5 +-
 scripts/list_new_commits.py                   |  60 +++---
 scripts/load-test.py                          | 126 ++++++------
 terraform/README.md                           |   1 -
 tests/conftest.py                             |   8 +-
 tests/test_build.py                           |  47 +++--
 tests/test_http.py                            |   2 +-
 tests/test_launch.py                          |  28 ++-
 61 files changed, 908 insertions(+), 892 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/repo_check.md b/.github/ISSUE_TEMPLATE/repo_check.md
index cddbf3a2b..fc1840318 100644
--- a/.github/ISSUE_TEMPLATE/repo_check.md
+++ b/.github/ISSUE_TEMPLATE/repo_check.md
@@ -2,7 +2,6 @@
 name: "\U00002705 Repo Check"
 about: "If you're concerned if your repository is acceptable for mybinder.org, we can check your repo"
 labels: question
-
 ---
 
 <!--
diff --git a/.github/ISSUE_TEMPLATE/request_resources.yml b/.github/ISSUE_TEMPLATE/request_resources.yml
index f504815c4..c0164c236 100644
--- a/.github/ISSUE_TEMPLATE/request_resources.yml
+++ b/.github/ISSUE_TEMPLATE/request_resources.yml
@@ -100,4 +100,3 @@ body:
       description: Anything else you'd like to tell us?
     validations:
       required: false
-
diff --git a/.github/workflows/cd.yml b/.github/workflows/cd.yml
index 5fafff450..4093c5445 100644
--- a/.github/workflows/cd.yml
+++ b/.github/workflows/cd.yml
@@ -64,9 +64,8 @@ jobs:
       ((github.event_name == 'push') && (github.ref == 'refs/heads/master')) ||
       ((github.event_name == 'push') && contains(github.ref, 'test-this-pr'))
     runs-on: ubuntu-20.04
-
     strategy:
-      fail-fast: false  # Do not cancel all jobs if one fails
+      fail-fast: false # Do not cancel all jobs if one fails
       matrix:
         include:
           # Now we have only one staging environment, but we have had two when
@@ -188,7 +187,7 @@ jobs:
     # We run this job multiple times with different parameters
     # - https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategy
     strategy:
-      fail-fast: false  # Do not cancel all jobs if one fails
+      fail-fast: false # Do not cancel all jobs if one fails
       matrix:
         include:
           - federation_member: prod
diff --git a/.github/workflows/watch-dependencies.yaml b/.github/workflows/watch-dependencies.yaml
index 4b2c5ff86..8a65d74d7 100644
--- a/.github/workflows/watch-dependencies.yaml
+++ b/.github/workflows/watch-dependencies.yaml
@@ -98,7 +98,6 @@ jobs:
             - Source code: ${{ matrix.source_url }}
             - Changelog: ${{ matrix.changelog_url }}
 
-
   update-chart-dependencies:
     # Don't schedule runs on forks, but allow the job to execute on push and
     # workflow_dispatch for CI development purposes.
diff --git a/README.md b/README.md
index 0107b4961..ce328874d 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,7 @@ Instead, you should review the [BinderHub documentation][] and the
 [Site Reliability Guide](https://mybinder-sre.readthedocs.io/en/latest/index.html), the collected wisdom of operating mybinder.org.
 
 Amongst other things the guide contains:
+
 - [How to do a deployment](https://mybinder-sre.readthedocs.io/en/latest/deployment/how.html)
 - [What happens during a deployment?](https://mybinder-sre.readthedocs.io/en/latest/deployment/what.html)
 - [Incident reports for past incidents](https://mybinder-sre.readthedocs.io/en/latest/incident-reports/incident_reports_toc.html)
@@ -38,20 +39,19 @@ Amongst other things the guide contains:
 
 ## Key Links
 
-|             | Staging | Production |
-| ----------- | ------- | ---------- |
-| Site     |[staging.mybinder.org](https://staging.mybinder.org) | [mybinder.org](https://mybinder.org) |
-| CI Deployment | [![Continuous Deployment](https://github.com/jupyterhub/mybinder.org-deploy/workflows/Continuous%20Deployment/badge.svg)](https://github.com/jupyterhub/mybinder.org-deploy/actions?query=workflow%3A%22Continuous+Deployment%22) (both) |
-| Deployment checklist | staging | prod |
-| Monitoring | staging | [prod](https://grafana.mybinder.org/dashboard/db/kubernetes-cluster-monitoring-binder-prod?refresh=60s&orgId=1) |
-
-| Helm chart  | dev | stable |
-|-------------|-----|--------|
-| JupyterHub  | [dev](https://jupyterhub.github.io/helm-chart/#development-releases-jupyterhub) | [stable](https://jupyterhub.github.io/helm-chart/#stable-releases) |
-| BinderHub | [dev](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)| - |
+|                      | Staging                                                                                                                                                                                                                                  | Production                                                                                                      |
+| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| Site                 | [staging.mybinder.org](https://staging.mybinder.org)                                                                                                                                                                                     | [mybinder.org](https://mybinder.org)                                                                            |
+| CI Deployment        | [![Continuous Deployment](https://github.com/jupyterhub/mybinder.org-deploy/workflows/Continuous%20Deployment/badge.svg)](https://github.com/jupyterhub/mybinder.org-deploy/actions?query=workflow%3A%22Continuous+Deployment%22) (both) |
+| Deployment checklist | staging                                                                                                                                                                                                                                  | prod                                                                                                            |
+| Monitoring           | staging                                                                                                                                                                                                                                  | [prod](https://grafana.mybinder.org/dashboard/db/kubernetes-cluster-monitoring-binder-prod?refresh=60s&orgId=1) |
 
+| Helm chart | dev                                                                             | stable                                                             |
+| ---------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
+| JupyterHub | [dev](https://jupyterhub.github.io/helm-chart/#development-releases-jupyterhub) | [stable](https://jupyterhub.github.io/helm-chart/#stable-releases) |
+| BinderHub  | [dev](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)  | -                                                                  |
 
 [mybinder.org]: https://mybinder.org
 [staging.mybinder.org]: https://staging.mybinder.org
 [`jupyterhub/binderhub`]: https://github.com/jupyterhub/binderhub
-[BinderHub documentation]: https://binderhub.readthedocs.io/en/latest/
+[binderhub documentation]: https://binderhub.readthedocs.io/en/latest/
diff --git a/WISDOM.md b/WISDOM.md
index 9e703626a..e354ef17b 100644
--- a/WISDOM.md
+++ b/WISDOM.md
@@ -1,4 +1,4 @@
 # A place to put the collective wisdom of the Binder project.
 
-* When you are in an outage, focus only on fixing the outage - do not try to do anything else.
-* Prefer minor annoyances happening infrequently but at regular intervals, rather than major annoyances happening rarely but at unpredictable intervals.
+- When you are in an outage, focus only on fixing the outage - do not try to do anything else.
+- Prefer minor annoyances happening infrequently but at regular intervals, rather than major annoyances happening rarely but at unpredictable intervals.
diff --git a/config/ovh.yaml b/config/ovh.yaml
index 195b896b3..4304d784c 100644
--- a/config/ovh.yaml
+++ b/config/ovh.yaml
@@ -35,7 +35,7 @@ binderhub:
       type: manual
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'false'
+      kubernetes.io/tls-acme: "false"
     hosts:
       - binder.mybinder.ovh
     tls:
@@ -58,7 +58,7 @@ binderhub:
     ingress:
       annotations:
         kubernetes.io/ingress.class: nginx
-        kubernetes.io/tls-acme: 'false'
+        kubernetes.io/tls-acme: "false"
       hosts:
         - hub-binder.mybinder.ovh
       tls:
@@ -95,7 +95,7 @@ grafana:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'false'
+      kubernetes.io/tls-acme: "false"
     hosts:
       - grafana-mybinder.mybinder.ovh
     tls:
@@ -124,7 +124,7 @@ prometheus:
     ingress:
       annotations:
         kubernetes.io/ingress.class: nginx
-        kubernetes.io/tls-acme: 'false'
+        kubernetes.io/tls-acme: "false"
       hosts:
         - prometheus-mybinder.mybinder.ovh
       tls:
@@ -132,7 +132,6 @@ prometheus:
             - prometheus-mybinder.mybinder.ovh
           secretName: tls-crt
 
-
 ingress-nginx:
   controller:
     hostNetwork: true
@@ -143,12 +142,11 @@ ingress-nginx:
   scope:
     enabled: false
 
-
 static:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'false'
+      kubernetes.io/tls-acme: "false"
     hosts:
       - static-mybinder.mybinder.ovh
     tls:
@@ -158,7 +156,7 @@ redirector:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'false'
+      kubernetes.io/tls-acme: "false"
     tls:
       secretName: tls-crt
   redirects:
diff --git a/config/prod.yaml b/config/prod.yaml
index 6ec6ad04d..99109247f 100644
--- a/config/prod.yaml
+++ b/config/prod.yaml
@@ -73,7 +73,6 @@ binderhub:
       userScheduler:
         nodeSelector: *coreNodeSelector
 
-
 grafana:
   nodeSelector: *coreNodeSelector
   resources:
diff --git a/config/turing.yaml b/config/turing.yaml
index 47c1f53db..fa0f89bdc 100644
--- a/config/turing.yaml
+++ b/config/turing.yaml
@@ -76,7 +76,7 @@ grafana:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'true'
+      kubernetes.io/tls-acme: "true"
     hosts:
       - grafana.mybinder.turing.ac.uk
     tls:
@@ -103,7 +103,7 @@ prometheus:
     ingress:
       annotations:
         kubernetes.io/ingress.class: nginx
-        kubernetes.io/tls-acme: 'true'
+        kubernetes.io/tls-acme: "true"
       hosts:
         - prometheus.mybinder.turing.ac.uk
         - prometheus.turing.mybinder.org
@@ -122,7 +122,6 @@ ingress-nginx:
     scope:
       enabled: true
 
-
 static:
   ingress:
     hosts:
diff --git a/deploy.py b/deploy.py
index afbee91d6..3a723e56c 100755
--- a/deploy.py
+++ b/deploy.py
@@ -9,9 +9,9 @@
 
 # Color codes for colored output!
 if os.environ.get("TERM"):
-    BOLD = subprocess.check_output(['tput', 'bold']).decode()
-    GREEN = subprocess.check_output(['tput', 'setaf', '2']).decode()
-    NC = subprocess.check_output(['tput', 'sgr0']).decode()
+    BOLD = subprocess.check_output(["tput", "bold"]).decode()
+    GREEN = subprocess.check_output(["tput", "setaf", "2"]).decode()
+    NC = subprocess.check_output(["tput", "sgr0"]).decode()
 else:
     # no term, no colors
     BOLD = GREEN = NC = ""
@@ -41,56 +41,56 @@ def setup_auth_turing(cluster):
 
     # Login in to Azure
     login_cmd = [
-        "az", "login", "--service-principal",
-        "--username", azure["sp-app-id"],
-        "--password", azure["sp-app-key"],
-        "--tenant", azure["tenant-id"]
+        "az",
+        "login",
+        "--service-principal",
+        "--username",
+        azure["sp-app-id"],
+        "--password",
+        azure["sp-app-key"],
+        "--tenant",
+        azure["tenant-id"],
     ]
     subprocess.check_output(login_cmd)
 
     # Set kubeconfig
     creds_cmd = [
-        "az", "aks", "get-credentials",
-        "--name", cluster,
-        "--resource-group", "binder-prod"
-
+        "az",
+        "aks",
+        "get-credentials",
+        "--name",
+        cluster,
+        "--resource-group",
+        "binder-prod",
     ]
     stdout = subprocess.check_output(creds_cmd)
-    print(stdout.decode('utf-8'))
+    print(stdout.decode("utf-8"))
 
 
 def setup_auth_ovh(release, cluster):
     """
     Set up authentication with 'ovh' K8S from the ovh-kubeconfig.yml
     """
-    print(f'Setup the OVH authentication for namespace {release}')
+    print(f"Setup the OVH authentication for namespace {release}")
 
-    ovh_kubeconfig = os.path.join(ABSOLUTE_HERE, 'secrets', 'ovh-kubeconfig.yml')
-    os.environ['KUBECONFIG'] = ovh_kubeconfig
-    print(f'Current KUBECONFIG=\'{ovh_kubeconfig}\'')
-    stdout = subprocess.check_output([
-        'kubectl',
-        'config',
-        'use-context',
-        cluster
-    ])
-    print(stdout.decode('utf8'))
+    ovh_kubeconfig = os.path.join(ABSOLUTE_HERE, "secrets", "ovh-kubeconfig.yml")
+    os.environ["KUBECONFIG"] = ovh_kubeconfig
+    print(f"Current KUBECONFIG='{ovh_kubeconfig}'")
+    stdout = subprocess.check_output(["kubectl", "config", "use-context", cluster])
+    print(stdout.decode("utf8"))
 
 
 def setup_ovh_ingress_link(release):
     """
     Setup the Ingress link ovh.mybinder.org -> binder.mybinder.ovh
     """
-    ovh_ingress_path = os.path.join(ABSOLUTE_HERE, 'config', 'ovh', 'ovh_mybinder_org_ingress.yaml')
-    stdout = subprocess.check_output([
-        'kubectl',
-        'apply',
-        '-f',
-        ovh_ingress_path,
-        '-n',
-        release
-    ])
-    print(stdout.decode('utf8'))
+    ovh_ingress_path = os.path.join(
+        ABSOLUTE_HERE, "config", "ovh", "ovh_mybinder_org_ingress.yaml"
+    )
+    stdout = subprocess.check_output(
+        ["kubectl", "apply", "-f", ovh_ingress_path, "-n", release]
+    )
+    print(stdout.decode("utf8"))
 
 
 def setup_auth_gcloud(release, cluster=None):
@@ -98,10 +98,14 @@ def setup_auth_gcloud(release, cluster=None):
     Set up GCloud + Kubectl authentication for talking to a given cluster
     """
     # Authenticate to GoogleCloud using a service account
-    subprocess.check_output([
-        "gcloud", "auth", "activate-service-account",
-        f"--key-file=secrets/gke-auth-key-{release}.json"
-    ])
+    subprocess.check_output(
+        [
+            "gcloud",
+            "auth",
+            "activate-service-account",
+            f"--key-file=secrets/gke-auth-key-{release}.json",
+        ]
+    )
 
     if not cluster:
         cluster = release
@@ -126,7 +130,9 @@ def setup_auth_gcloud(release, cluster=None):
 def assert_helm_v3():
     """Asserts helm is available at all and of the required major version."""
     c = subprocess.run(["helm", "--help"], capture_output=True)
-    assert c.returncode == 0, "Helm 3 is required, but helm doesn't seem to be installed!"
+    assert (
+        c.returncode == 0
+    ), "Helm 3 is required, but helm doesn't seem to be installed!"
 
     c = subprocess.run(
         ["helm", "version", "--short"],
@@ -134,7 +140,9 @@ def assert_helm_v3():
         stdout=subprocess.PIPE,
         stderr=subprocess.STDOUT,
     )
-    assert c.returncode == 0 and "v3." in c.stdout, "Helm 3 is required, but a different version seem to be installed!"
+    assert (
+        c.returncode == 0 and "v3." in c.stdout
+    ), "Helm 3 is required, but a different version seem to be installed!"
 
 
 def deploy(release, name=None):
@@ -177,7 +185,9 @@ def deploy(release, name=None):
 
     # common config files
     config_files = sorted(glob.glob(os.path.join("config", "common", "*.yaml")))
-    config_files.extend(sorted(glob.glob(os.path.join("secrets", "config", "common", "*.yaml"))))
+    config_files.extend(
+        sorted(glob.glob(os.path.join("secrets", "config", "common", "*.yaml")))
+    )
     # release-specific config files
     for config_dir in ("config", "secrets/config"):
         config_files.append(os.path.join(config_dir, release + ".yaml"))
@@ -186,7 +196,9 @@ def deploy(release, name=None):
         helm.extend(["-f", config_file])
 
     subprocess.check_call(helm)
-    print(BOLD + GREEN + f"SUCCESS: Helm upgrade for {release} completed" + NC, flush=True)
+    print(
+        BOLD + GREEN + f"SUCCESS: Helm upgrade for {release} completed" + NC, flush=True
+    )
 
     # Explicitly wait for all deployments and daemonsets to be fully rolled out
     print(
@@ -273,15 +285,19 @@ def main():
         choices=["staging", "prod", "ovh", "turing"],
     )
     argparser.add_argument(
-        "--name", help="Override helm release name, if different from RELEASE",
+        "--name",
+        help="Override helm release name, if different from RELEASE",
     )
     argparser.add_argument(
-        "cluster", help="Cluster to do the deployment in", nargs="?", type=str,
+        "cluster",
+        help="Cluster to do the deployment in",
+        nargs="?",
+        type=str,
     )
     argparser.add_argument(
-        '--local',
-        action='store_true',
-        help="If the script is running locally, skip auth step"
+        "--local",
+        action="store_true",
+        help="If the script is running locally, skip auth step",
     )
 
     args = argparser.parse_args()
@@ -312,14 +328,12 @@ def main():
                 pass
             else:
                 # User wrote something that wasn't "yes" or "no"
-                raise ValueError(
-                    "Unrecognised input. Expecting either yes or no."
-                )
+                raise ValueError("Unrecognised input. Expecting either yes or no.")
 
         # script is running on CI, proceed with auth and helm setup
-        if args.cluster == 'ovh':
+        if args.cluster == "ovh":
             setup_auth_ovh(args.release, args.cluster)
-        elif args.cluster == 'turing':
+        elif args.cluster == "turing":
             setup_auth_turing(args.release)
         else:
             setup_auth_gcloud(args.release, args.cluster)
@@ -327,5 +341,5 @@ def main():
     deploy(args.release, args.name)
 
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     main()
diff --git a/docs/source/components/cloud.md b/docs/source/components/cloud.md
index 2ef1cd8a9..cb2244cdb 100644
--- a/docs/source/components/cloud.md
+++ b/docs/source/components/cloud.md
@@ -6,7 +6,7 @@ This document lists the various cloud products we use, and how we use them.
 ## Philosophy
 
 We use **only** commodity cloud products - things that can be easily
-replicated in other clouds *and* bare-metal hardware. This gives us
+replicated in other clouds _and_ bare-metal hardware. This gives us
 several technical and social advantages:
 
 1. We avoid vendor lock-in, and can migrate providers if need be
@@ -72,8 +72,8 @@ The `prod` cluster currently uses `n1-highmem-32` machines. These have
 32 CPU cores and 208 GB of Memory. We use the `highmem` machines (with more Memory per CPU)
 as opposed to `standard` machines for the following reasons:
 
-1. Memory is an *incompressible* resource - once you give a process memory, you can
-   not take it away without killing the process. CPU is *compressible* - you can
+1. Memory is an _incompressible_ resource - once you give a process memory, you can
+   not take it away without killing the process. CPU is _compressible_ - you can
    take away how much CPU a process is using without killing it.
 2. Our users generally seem to be running not-very-cpu-intensive code, as can be
    witnessed from our generally low CPU usage.
@@ -81,8 +81,8 @@ as opposed to `standard` machines for the following reasons:
    pulling images leads to faster startup times for users. Using larger nodes
    increases the cache hit rate, so we use nodes with more rather than less RAM.
 
-*tl;dr: Using `highmem` machines saves us a lot of money, since we are not paying for CPU
-we are not using!*
+_tl;dr: Using `highmem` machines saves us a lot of money, since we are not paying for CPU
+we are not using!_
 
 The `staging` cluster uses much smaller machines than the production one, to keep costs
 down.
@@ -94,7 +94,7 @@ the disk [controls the performance](https://cloud.google.com/compute/docs/disks/
 are doing a lot of I/O operations during docker build / push / pull / run, so we
 use SSDs.
 
-Note that SSD boot disks are *not* a feature available on GKE to all customers -
+Note that SSD boot disks are _not_ a feature available on GKE to all customers -
 we have been given [early access](https://github.com/kubernetes/kubernetes/issues/36499)
 to this feature, since it makes a dramatic difference to our performance (and
 we knew where to ask!).
@@ -125,7 +125,6 @@ We use Google Cloud's hosted docker registry - [Google Container Registry (GCR)]
 This lets us use a standard mechanism for storing and retrieving docker images
 without having to run any of that infrastructure ourselves.
 
-
 ### Authentication
 
 GCR is private by default, and can be only used from inside the Google Cloud project
@@ -172,7 +171,7 @@ The code for generating the image name from repository information is
 in [binderhub's builder.py](https://github.com/jupyterhub/binderhub/blob/master/binderhub/builder.py),
 under `_generate_build_name`.
 
-Sometimes, we *do* want to invalidate all previously built images - for example,
+Sometimes, we _do_ want to invalidate all previously built images - for example,
 when we do a major notebook version bump. This will cause all repositories to be
 rebuilt the next time they are launched. There is a performance cost to this, so
 this invalidation has to be done judiciously. This is done by giving all the images
diff --git a/docs/source/components/dashboards.md b/docs/source/components/dashboards.md
index 79a3eb606..1e3557516 100644
--- a/docs/source/components/dashboards.md
+++ b/docs/source/components/dashboards.md
@@ -9,6 +9,7 @@ is going wrong during / after an outage.
 ## What is it?
 
 ```{image} ../_static/images/dashboard.png
+
 ```
 
 A dashboard is a set of pre-defined graphs in a particular layout that
diff --git a/docs/source/components/ingress.md b/docs/source/components/ingress.md
index 6753b9926..611769a50 100644
--- a/docs/source/components/ingress.md
+++ b/docs/source/components/ingress.md
@@ -52,24 +52,24 @@ present with `kubectl --namespace=prod get ingress`.
 
 The following ingress objects currently exist:
 
-* `jupyterhub` - Directs traffic to `hub.mybinder.org`.
+- `jupyterhub` - Directs traffic to `hub.mybinder.org`.
   The zero-to-jupyterhub guide has more [documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/advanced.html#ingress).
-* `binderhub` - Directs traffic to `mybinder.org`. You can find more details
-   about this in the [binderhub helm chart](https://github.com/jupyterhub/binderhub/tree/master/helm-chart).
-* `redirector` - Directs traffic to the HTTP redirector we run for `mybinder.org`.
-   This helps do redirects such as `docs.mybinder.org` or `beta.mybinder.org`.
-   The list of redirects is configured in `mybinder/values.yaml`. The code
-   for this is in `mybinder/templates/redirector` in this repo.
-* `static` - Directs traffic into `static.mybinder.org`. We serve the `mybinder.org`
-   badges from a different domain for [privacy reasons](https://github.com/jupyterhub/binderhub/issues/379).
-   This ingress lets us direct traffic only from `static.mybinder.org/badge.svg` to the
-   binder pod.
-* `prometheus-server` - Directs traffic to `prometheus.mybinder.org`. Configured under
+- `binderhub` - Directs traffic to `mybinder.org`. You can find more details
+  about this in the [binderhub helm chart](https://github.com/jupyterhub/binderhub/tree/master/helm-chart).
+- `redirector` - Directs traffic to the HTTP redirector we run for `mybinder.org`.
+  This helps do redirects such as `docs.mybinder.org` or `beta.mybinder.org`.
+  The list of redirects is configured in `mybinder/values.yaml`. The code
+  for this is in `mybinder/templates/redirector` in this repo.
+- `static` - Directs traffic into `static.mybinder.org`. We serve the `mybinder.org`
+  badges from a different domain for [privacy reasons](https://github.com/jupyterhub/binderhub/issues/379).
+  This ingress lets us direct traffic only from `static.mybinder.org/badge.svg` to the
+  binder pod.
+- `prometheus-server` - Directs traffic to `prometheus.mybinder.org`. Configured under
   `prometheus` in both `mybinder/values.yaml` and `config/prod.yaml`.
-* `grafana` - Directs traffic to `grafana.mybinder.org`. Configured under `grafana` in
-   both `mybinder/values.yaml` and `config/prod.yaml`.
-* `kube-lego-nginx` - Used by kube-lego for doing automatic
-   HTTPS certificate renewals.
+- `grafana` - Directs traffic to `grafana.mybinder.org`. Configured under `grafana` in
+  both `mybinder/values.yaml` and `config/prod.yaml`.
+- `kube-lego-nginx` - Used by kube-lego for doing automatic
+  HTTPS certificate renewals.
 
 ## HTTPS certificates with kube-lego
 
diff --git a/docs/source/components/metrics.md b/docs/source/components/metrics.md
index 8cdbd6de7..350c15a15 100644
--- a/docs/source/components/metrics.md
+++ b/docs/source/components/metrics.md
@@ -14,47 +14,46 @@ We use [Prometheus](https://prometheus.io/) to store and query our metrics.
 ### What is Prometheus?
 
 Prometheus is a [Time Series Database](https://en.wikipedia.org/wiki/Time_series_database)
-optimized for storing operational metrics. It stores all data as 
-streams of timestamped values belonging to the same **metric** and the 
+optimized for storing operational metrics. It stores all data as
+streams of timestamped values belonging to the same **metric** and the
 same set of **labels**.
 
-The **metric name** specifies the general feature of a system that is 
-measured (e.g. `http_requests_total` - the total number of HTTP requests received). 
+The **metric name** specifies the general feature of a system that is
+measured (e.g. `http_requests_total` - the total number of HTTP requests received).
 
-A set of labels for the same metric name identifies a particular 
-dimensional instantiation of that metric (for example: all HTTP requests 
+A set of labels for the same metric name identifies a particular
+dimensional instantiation of that metric (for example: all HTTP requests
 that used the method `POST` to the `/api/tracks` handler would be represented
 as the time series `http_requests_total{method="POST", handler="/api/tracks"}`).
 
-The prometheus documentation has more information on its 
+The prometheus documentation has more information on its
 [data model](https://prometheus.io/docs/concepts/data_model/) and the different
 [kinds of time series](https://prometheus.io/docs/concepts/metric_types/) available.
 These two pages are fairly short and are highly recommended reading!
 
 ### Querying
 
-Prometheus has its own query language called 
+Prometheus has its own query language called
 [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/),
-optimized for time series queries. 
+optimized for time series queries.
 
 The prometheus documentation has fairly clear and thorough documentation
 on PromQL - [basics](https://prometheus.io/docs/prometheus/latest/querying/basics/),
-[operators](https://prometheus.io/docs/prometheus/latest/querying/operators/) 
+[operators](https://prometheus.io/docs/prometheus/latest/querying/operators/)
 and [functions](https://prometheus.io/docs/prometheus/latest/querying/functions/).
-You do not need to become an expert, but a basic understanding is useful. 
+You do not need to become an expert, but a basic understanding is useful.
 There are also [examples](https://prometheus.io/docs/prometheus/latest/querying/examples/)
 to pick up and play with!
 
 [prometheus.mybinder.org](https://prometheus.mybinder.org/graph) is our public
-prometheus installation, and you can practice your queries there! 
-
+prometheus installation, and you can practice your queries there!
 
 ### Metrics Ingestion
 
-Prometheus uses a **pull** model for metrics. It has a list of 
+Prometheus uses a **pull** model for metrics. It has a list of
 targets, and constantly polls them for their current state, and
 records what it gets back. The targets are supposed to respond
-to these HTTP requests with data in the 
+to these HTTP requests with data in the
 [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/).
 
 Our data is currently sourced from the following targets.
@@ -63,7 +62,7 @@ Our data is currently sourced from the following targets.
 
 The [node_exporter](https://github.com/prometheus/node_exporter) exports
 information about each node we run - CPU usage, memory left, disk space,
-etc. It provides fairly detailed info, usually prefixed with `node_`. 
+etc. It provides fairly detailed info, usually prefixed with `node_`.
 This is not kubernetes specific.
 
 #### Kubernetes information
@@ -75,7 +74,7 @@ prefixed with `kube_`.
 
 These only contain information from kubernetes API itself. For example,
 'how much RAM are these containers using' is not recorded by `kube-state-metrics`,
-since that is not information that is available to the Kubernetes API. 
+since that is not information that is available to the Kubernetes API.
 'how much RAM are these pods requesting' is, however, available.
 
 #### Container information
@@ -97,13 +96,13 @@ These metrics are prefixed with `nginx_`.
 #### BinderHub information
 
 [BinderHub](https://github.com/jupyterhub/binderhub) itself exposes
-metrics about its operations in the prometheus format, using 
+metrics about its operations in the prometheus format, using
 the [python prometheus client library](https://github.com/prometheus/client_python).
 These are currently somewhat limited, and prefixed with `binderhub_`
 
 ### Configuration
 
-Prometheus is installed using the 
+Prometheus is installed using the
 [prometheus helm chart](https://github.com/helm/charts/tree/master/stable/prometheus).
 This installs the following components:
 
diff --git a/docs/source/conf.py b/docs/source/conf.py
index 514eaaa29..73e60e95e 100644
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -19,15 +19,15 @@
 ]
 
 # The suffix(es) of source filenames.
-source_suffix = ['.rst', '.md']
+source_suffix = [".rst", ".md"]
 
 # The root toctree document.
 root_doc = master_doc = "index"
 
 # General information about the project.
-project = 'Site Reliability Guide for mybinder.org'
-copyright = f'2017 - {datetime.now().year}, Binder Team'
-author = 'Binder Team'
+project = "Site Reliability Guide for mybinder.org"
+copyright = f"2017 - {datetime.now().year}, Binder Team"
+author = "Binder Team"
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
@@ -61,7 +61,7 @@
 linkcheck_ignore = [
     r"(.*)github\.com(.*)#",  # javascript based anchors
     r"(.*)/#%21(.*)/(.*)",  # /#!forum/jupyter - encoded anchor edge case
-    "https://grafana.mybinder.org", # likely no longer functional links from incident reports
+    "https://grafana.mybinder.org",  # likely no longer functional links from incident reports
     "https://console.cloud.google.com",  # sign-in redirect noise
     "https://console.developers.google.com",  # sign-in redirect noise
 ]
diff --git a/docs/source/deployment/how.md b/docs/source/deployment/how.md
index fc7cb62db..cf2b8c1ad 100644
--- a/docs/source/deployment/how.md
+++ b/docs/source/deployment/how.md
@@ -22,14 +22,14 @@ However, we have left the manual steps here for provenance or in case of emergen
 Deployments to mybinder.org should be:
 
 1. **Safe**. We will have good, user friendly tooling + lots of safeguards,
-so people can deploy without fear of accidentally breaking the site.
+   so people can deploy without fear of accidentally breaking the site.
 
 2. **Straightforward**. We want a lot of people to be involved in maintaining mybinder.org,
-so we must make sure deployments are also easy to do. Most deployments should
-not require specific sysadmin knowledge.
+   so we must make sure deployments are also easy to do. Most deployments should
+   not require specific sysadmin knowledge.
 
 3. **Timely**. We deploy changes to repo2docker and BinderHub within a few days of
-them being merged into master.
+   them being merged into master.
 
 These are all **aspirational** - we strive for hitting the above points,
 but recognize that work and life may get in the way of doing this perfectly.
@@ -44,48 +44,47 @@ The version of the BinderHub Helm chart is declared in `mybinder/Chart.yaml`.
 Upgrading the version of BinderHub that is used in mybinder.org corresponds to
 updating the BinderHub Helm chart version, which we step through below.
 
-1. Merge changes to BinderHub.
-2. Open the [branches page for the BinderHub travis account](https://travis-ci.org/jupyterhub/binderhub/branches).
-3. Wait for the build for your PR merge to pass (it will say "#NNN passed").
-   If it does, then continue to step 4. If it doesn't, take a look at the error message, and debug as needed
-   until they pass.
-4. Run the `list_new_commits.py` script in the `scripts/` of the
-   `mybinder.org-deploy` repository. It will output something like the following:
+1.  Merge changes to BinderHub.
+2.  Open the [branches page for the BinderHub travis account](https://travis-ci.org/jupyterhub/binderhub/branches).
+3.  Wait for the build for your PR merge to pass (it will say "#NNN passed").
+    If it does, then continue to step 4. If it doesn't, take a look at the error message, and debug as needed
+    until they pass.
+4.  Run the `list_new_commits.py` script in the `scripts/` of the
+    `mybinder.org-deploy` repository. It will output something like the following:
 
-       ---------------------
+        ---------------------
 
-       BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
-       repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
-       JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
+        BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
+        repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
+        JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
 
-       ---------------------
+        ---------------------
 
-   Since you are updating BinderHub, copy the text in `<NEW-HASH>` for the
-   line that refers to BinderHub. This is the name of the new BinderHub image.
-   We'll now update the config to refer to this image.
+    Since you are updating BinderHub, copy the text in `<NEW-HASH>` for the
+    line that refers to BinderHub. This is the name of the new BinderHub image.
+    We'll now update the config to refer to this image.
 
-5. In your fork of the [mybinder.org-deploy](https://github.com/jupyterhub/mybinder.org-deploy)
-   repository, open `mybinder/Chart.yaml`.
-6. Toward the end of the file, you will see lines similar to:
+5.  In your fork of the [mybinder.org-deploy](https://github.com/jupyterhub/mybinder.org-deploy)
+    repository, open `mybinder/Chart.yaml`.
+6.  Toward the end of the file, you will see lines similar to:
 
-      - name: binderhub
-        version: 0.2.0-n454.h97fb8c3
-        repository: https://jupyterhub.github.io/helm-chart
+    - name: binderhub
+      version: 0.2.0-n454.h97fb8c3
+      repository: https://jupyterhub.github.io/helm-chart
 
-   Where `97fb8c3` following `.h`, a prefix for hash, is the same value printed
-   in `<OLD-HASH>` above.
+    Where `97fb8c3` following `.h`, a prefix for hash, is the same value printed
+    in `<OLD-HASH>` above.
 
-   Replace this hash with the text in `<NEW-HASH>` above. For example, in the
-   above case, we'll replace it with the new hash.
+    Replace this hash with the text in `<NEW-HASH>` above. For example, in the
+    above case, we'll replace it with the new hash.
 
-      - name: binderhub
-        version: 0.2.0-n457.hdc3df7f
-        repository: https://jupyterhub.github.io/helm-chart
-
-7. Merge this change to `mybinder/Chart.yaml` into the mybinder.org-deploy
-   repository following the steps in the [Deploying a change](deploying-a-change) section
-   to deploy the change.
+    - name: binderhub
+      version: 0.2.0-n457.hdc3df7f
+      repository: https://jupyterhub.github.io/helm-chart
 
+7.  Merge this change to `mybinder/Chart.yaml` into the mybinder.org-deploy
+    repository following the steps in the [Deploying a change](deploying-a-change) section
+    to deploy the change.
 
 ## Updating repo2docker
 
@@ -97,84 +96,85 @@ the repo2docker repository, a new version of this image is pushed. We then confi
 BinderHub to use the newly built image (which is identified by a tag) by editing `values.yaml`.
 The following lines describe how to point mybinder.org to the new repo2docker image
 
-1. Merge changes to repo2docker.
-2. Open the [branches page for repo2docker](https://travis-ci.org/jupyter/repo2docker/branches).
-   And click on the number for the latest build on "Master".
-3. Wait for the build for your PR merge to pass (it will say "#NNN passed").
-   If it does, then continue to step 4. If it doesn't, take a look at the error message, and debug as needed
-   until they pass.
-4. Run the `list_new_commits.py` script in the `scripts/` of the
-   `mybinder.org-deploy` repository. It will output something like the following:
+1.  Merge changes to repo2docker.
+2.  Open the [branches page for repo2docker](https://travis-ci.org/jupyter/repo2docker/branches).
+    And click on the number for the latest build on "Master".
+3.  Wait for the build for your PR merge to pass (it will say "#NNN passed").
+    If it does, then continue to step 4. If it doesn't, take a look at the error message, and debug as needed
+    until they pass.
+4.  Run the `list_new_commits.py` script in the `scripts/` of the
+    `mybinder.org-deploy` repository. It will output something like the following:
 
-       ---------------------
+        ---------------------
 
-       BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
-       repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
-       JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
+        BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
+        repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
+        JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
 
-       ---------------------
+        ---------------------
 
-   Since you are updating repo2docker, copy the text in `<NEW-HASH>` for the
-   line that refers to repo2docker. This is the name of the new repo2docker image.
-   We'll now update the config to refer to this image.
+    Since you are updating repo2docker, copy the text in `<NEW-HASH>` for the
+    line that refers to repo2docker. This is the name of the new repo2docker image.
+    We'll now update the config to refer to this image.
 
-5. In your fork of the mybinder.org-deploy repository, open
-  `mybinder/values.yaml`.
-6. Somewhere in the file you will see `repo2dockerImage`, it will look like
-   this:
+5.  In your fork of the mybinder.org-deploy repository, open
+    `mybinder/values.yaml`.
+6.  Somewhere in the file you will see `repo2dockerImage`, it will look like
+    this:
 
-       BinderHub:
-         build_image: jupyter/repo2docker:65d5411
+        BinderHub:
+          build_image: jupyter/repo2docker:65d5411
 
-   Where `65d5411` is the same value in `<OLD-HASH>` above.
+    Where `65d5411` is the same value in `<OLD-HASH>` above.
 
-7. Replace the *old* hash that is there with what you copied in step 4.
-   For example, the edited file will look similar to:
+7.  Replace the _old_ hash that is there with what you copied in step 4.
+    For example, the edited file will look similar to:
 
-       BinderHub:
-         build_image: jupyter/repo2docker:<NEW-HASH>
+        BinderHub:
+          build_image: jupyter/repo2docker:<NEW-HASH>
 
-8. Merge this change to `mybinder/values.yaml` into the mybinder.org-deploy
-   repository following the steps in the [Deploying a change](deploying-a-change) section
-   to deploy the change.
+8.  Merge this change to `mybinder/values.yaml` into the mybinder.org-deploy
+    repository following the steps in the [Deploying a change](deploying-a-change) section
+    to deploy the change.
 
 (deploying-a-change)=
+
 ## Deploying a change
 
-### Deploying to *both* `staging` then `prod`
+### Deploying to _both_ `staging` then `prod`
 
 Deploying a change involves making a PR with your desired change and merging it to
 master.
 
-1. Make the changes as described above [on your fork of this repo](https://github.com/jupyterhub/mybinder.org-deploy).
-2. Keep track of the **hashes** that were updated. You should have both the *old* hash that
-   was replaced, and the *new* hash that replaced it.
-3. If you haven't already, run the `list_new_commits.py` script in the `scripts/`
-   folder. This will print out a URL that describes the changes made to both
-   BinderHub and repo2docker.
-4. Make a PR to the `master` branch with the changes you want.
+1.  Make the changes as described above [on your fork of this repo](https://github.com/jupyterhub/mybinder.org-deploy).
+2.  Keep track of the **hashes** that were updated. You should have both the _old_ hash that
+    was replaced, and the _new_ hash that replaced it.
+3.  If you haven't already, run the `list_new_commits.py` script in the `scripts/`
+    folder. This will print out a URL that describes the changes made to both
+    BinderHub and repo2docker.
+4.  Make a PR to the `master` branch with the changes you want.
 
-    * Name the PR like so: `<TOOL-CHANGED>: <OLD-HASH>...<NEW-HASH>`
-    * In the description of the PR, paste the full URL that you printed out
+    - Name the PR like so: `<TOOL-CHANGED>: <OLD-HASH>...<NEW-HASH>`
+    - In the description of the PR, paste the full URL that you printed out
       `list_new_commits.py`. It should have the following form:
 
           https://github.com/jupyterhub/<REPO-NAME>/compare/<OLD-HASH>...<NEW-HASH>
 
-5. Review, accept, and merge this PR. This will make GitHub Actions deploy the changes
-   to [staging.mybinder.org](https://staging.mybinder.org), and run tests in the `tests/`
-   directory against it. **In this case, you can merge your own PR**. Note that if the
-   PR is a large change to the Kubernetes setup, this may take some time, and GitHub Actions may
-   time-out in the process. If this happens and you _expect_ it to happen, you can restart
-   the build a few times.
-6. If the tests succeed, the change will be deployed to mybinder.org.
-7. If the tests fail, the change will *not* be deployed to mybinder.org.
-   You must then investigate why it failed. **If you can
-   not figure out a cause in about 10 minutes, revert the change.**
-   You can revert the change with [the GitHub UI](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request) and immediately
-   merge the reversion PR that GitHub creates.
-8. Troubleshoot and make changes to your fork. Repeat the process from Step 1.
-
-### Deploying to *only* `staging`
+5.  Review, accept, and merge this PR. This will make GitHub Actions deploy the changes
+    to [staging.mybinder.org](https://staging.mybinder.org), and run tests in the `tests/`
+    directory against it. **In this case, you can merge your own PR**. Note that if the
+    PR is a large change to the Kubernetes setup, this may take some time, and GitHub Actions may
+    time-out in the process. If this happens and you _expect_ it to happen, you can restart
+    the build a few times.
+6.  If the tests succeed, the change will be deployed to mybinder.org.
+7.  If the tests fail, the change will _not_ be deployed to mybinder.org.
+    You must then investigate why it failed. **If you can
+    not figure out a cause in about 10 minutes, revert the change.**
+    You can revert the change with [the GitHub UI](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request) and immediately
+    merge the reversion PR that GitHub creates.
+8.  Troubleshoot and make changes to your fork. Repeat the process from Step 1.
+
+### Deploying to _only_ `staging`
 
 Sometimes you want to test out a deployment live before you make a deployment to `prod`.
 There are a few ways we can achieve this.
@@ -217,6 +217,7 @@ to staging only, follow these steps:
 
 The [what](what) document has more details on common ways deployments can go
 wrong, and how to debug them.
+
 ## Changing the mybinder.org infrastructure
 
 Sometimes we need to make changes to the mybinder.org core infrastructure.
diff --git a/docs/source/deployment/prereqs.md b/docs/source/deployment/prereqs.md
index ec98c50c1..a4e5796ce 100644
--- a/docs/source/deployment/prereqs.md
+++ b/docs/source/deployment/prereqs.md
@@ -36,9 +36,9 @@ have a working knowledge of how to use helm. Detailed explanations are out of th
 scope of this repository, but [docs.helm.sh](https://docs.helm.sh) is an excellent
 source of information. At a minimum, you must at least understand:
 
-* [What is a chart?](https://helm.sh/docs/chart_template_guide/getting_started/#charts)
-* [What are values files?](https://helm.sh/docs/chart_template_guide/values_files/)
-* [How do chart dependencies work?](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/)
+- [What is a chart?](https://helm.sh/docs/chart_template_guide/getting_started/#charts)
+- [What are values files?](https://helm.sh/docs/chart_template_guide/values_files/)
+- [How do chart dependencies work?](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/)
 
 ## Travis
 
diff --git a/docs/source/deployment/what.md b/docs/source/deployment/what.md
index faf5f67eb..b6ff6b3e7 100644
--- a/docs/source/deployment/what.md
+++ b/docs/source/deployment/what.md
@@ -1,12 +1,12 @@
 # What does a MyBinder.org deployment do?
 
-This document tries to explain *what* is going on when a deployment
-to mybinder.org happens. For *how* to do a deploy, please see [how](how).
+This document tries to explain _what_ is going on when a deployment
+to mybinder.org happens. For _how_ to do a deploy, please see [how](how).
 
 The deployment happens in various **stages**, each of which comprise of
 a series of **steps**. Each step of the deployment is
 controlled by `.travis.yml`, which should be considered the authoritative
-source of truth for deployment. *If this document disagrees with it,`.travis.yml` is correct!*
+source of truth for deployment. _If this document disagrees with it,`.travis.yml` is correct!_
 
 If any of the steps in any stage fails, all following steps
 are canceled and the deployment is marked as failed.
@@ -16,8 +16,9 @@ are canceled and the deployment is marked as failed.
 ### Step 1: Install all the things!
 
 #### Background
-Deployment requires the following tools to be installed. Note: 
-since deployments are handled with *Travis CI*, you don't
+
+Deployment requires the following tools to be installed. Note:
+since deployments are handled with _Travis CI_, you don't
 need them on your local computer.
 
 1. [`gcloud`](https://cloud.google.com/sdk/)
@@ -25,7 +26,7 @@ need them on your local computer.
    mybinder.org currently runs on [Google Cloud](https://cloud.google.com)
    in a [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)
    cluster. We need `gcloud` to authenticate ourselves to this cluster.
-   
+
 2. [`helm`](https://helm.sh)
 
    `helm` is the package manager for Kubernetes. We use this for actually installing
@@ -37,7 +38,7 @@ need them on your local computer.
    `kubectl` is the canonical command line client for interacting with the Kubernetes
    API. We primarily use it to explicitly wait for our deployment to complete
    before running our tests.
-   
+
 4. [`pytest`](https://docs.pytest.org)
 
    We use `pytest` to verify that our deployment successfully completed, by running
@@ -49,12 +50,12 @@ need them on your local computer.
 
    We have a bunch of secrets (in `secrets/`) in our deployment - things like
    cloud credentials, etc. We use `git-crypt` to keep them in this repository
-   in an encrypted form. We use the [encrypted travis file](https://docs.travis-ci.com/user/encrypting-files/) 
+   in an encrypted form. We use the [encrypted travis file](https://docs.travis-ci.com/user/encrypting-files/)
    for our repository to store the `git-crypt` decryption key.
-   
+
 #### What happens
 
-* All of the tools above are installed. We use the `before_deploy` section
+- All of the tools above are installed. We use the `before_deploy` section
   in `.travis.yml` to install these, mostly so we get nice log folding. The only exception
   is the `pytest` installation - that is in the `install` section, so we can leverage
   [travis caching](https://docs.travis-ci.com/user/caching/) to speed up our deploys.
@@ -64,19 +65,19 @@ need them on your local computer.
 All **Stage 1** failures can be attributed to one of the following causes:
 
 1. Network connections from Travis are being flaky, leading to failed installations
-   
+
    This is the most likely cause of Stage 1 failures. When this happens, we have no choice
    but to restart the Travis Build.
-   
+
    If a restart also fails, there are two possible reasons:
-   
+
    1. Travis is having some infrastructure issues. Check the [Travis Status Page](https://www.traviscistatus.com/)
       to see if this is the case.
    2. The method we are using to install any of these bits of software is
       having issues - either it no longer works due to some changes to the software, or
       the software installer is depending on things that are having temporary difficulties.
       Look at which software installation is failing, and debug that!
-   
+
 2. The commit we are trying to deploy modified `.travis.yml`, and introduced a bug / typo.
 
    The person who wrote the PR modifying `.travis.yml` should debug what
@@ -97,14 +98,14 @@ The following secrets are present in encrypted form in the repository:
    for both the staging and production Google cloud projects
    (as `secrets/gke-auth-key-staging.json` and `secrets/gke-auth-key-prod.json`).
    These have a [custom Role](https://cloud.google.com/iam/docs/understanding-roles)
-   called `travis-deployer` that gives them *just* the permissions needed to do
+   called `travis-deployer` that gives them _just_ the permissions needed to do
    deployments.
 3. A [GitHub deploy key](https://developer.github.com/v3/guides/managing-deploy-keys/)
    for the [binderhub-ci-repos/cached-minimal-dockerfile](https://github.com/binderhub-ci-repos/cached-minimal-dockerfile)
-   repo (as `secrets/binderhub-ci-repos-deploy-key`). This is used in our tests to force the 
+   repo (as `secrets/binderhub-ci-repos-deploy-key`). This is used in our tests to force the
    deployed binderhub to do a build + launch, rather than just a launch (via
    `tests/test_build.py`)
- 
+
 The `git-crypt` symmetric key needed to decrypt these secrets is `travis/crypt-key.enc`,
 encrypted with Travis's [encrypted file](https://docs.travis-ci.com/user/encrypting-files/)
 support. Travis only supports one encrypted file per repo, and these are one-way encrypted
@@ -125,19 +126,18 @@ are available in unencrypted form.
    key), and committed this change. This causes issues because `travis encrypt-file`
    can only encrypt one file per repo, so if you encrypt another file the first file
    becomes undecryptable.
-   
+
    This will manifest as an error from the `openssl` command.
-   
+
    The simplest fix is to revert the PR that encrypted another file. `git-crypt`
    should be used instead for encrypting additional files.
-   
-   
+
 ### Step 2: Setting up Helm
 
 #### Background
 
 We use _helm charts_
-to configure mybinder.org. We use charts both from the 
+to configure mybinder.org. We use charts both from the
 [official kubernetes charts repository](https://github.com/helm/charts),
 as well as the [JupyterHub charts repository](https://jupyterhub.github.io/helm-chart).
 
@@ -152,7 +152,7 @@ To set up helm to do the deployment, we do the following:
 3. Fetch all the dependencies of the `mybinder` deployment chart with the versions
    specified in `mybinder/Chart.yaml`, and store them locally to ready them
    for deployment.
-   
+
 At the end of this step, `helm` has been fully configured to do deployment of our
 charts.
 
@@ -161,14 +161,14 @@ charts.
 1. Invalid version for a dependency in `mybinder/Chart.yaml`
 
    This manifests as an error from `helm dep up` that looks like the following:
-   
+
    ```
    Error: Can't get a valid version for repositories <dependency>. Try changing the version constraint in Chart.yaml
    ```
-   
+
    `<dependency>` in the above error message should point to the erroring dependency
    whose version needs to be fixed.
-   
+
    If this happens for the **binderhub** dependency, the most common reason is that
    you have not waited long enough after merging a PR in the binderhub repo before
    bumping the version here. Make sure the version of binderhub is visible in
@@ -206,7 +206,7 @@ following:
    and [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
    objects to be fully ready. Theoretically the `--wait` param to `helm upgrade` does
    this - but it is not complete enough for our use case.
-   
+
 Once we have verified that all the `Deployment` and `DaemonSet` objects are ready,
 the helm deployment is complete!
 
@@ -216,28 +216,28 @@ the helm deployment is complete!
 
    YAML syntax can be finnicky sometimes, and fail in non-obvious ways. The most common
    error is the presence of tab characters in YAML, which will make them always fail.
-   
+
    Learn X in Y Minutes also has a nice [guide on YAML](https://learnxinyminutes.com/docs/yaml/).
    You can also use [yamllint](https://github.com/adrienverge/yamllint) locally to validate
    your YAML files.
-   
+
    Remember to **not** copy paste any secret files into online YAML Linting applications
    for linting! That could possibly compromise mybinder.org.
-   
+
 2. Kubernetes cluster is having difficulties
 
    This is usually manifested by either `helm` or `kubectl` reporting connection errors.
-   
+
 3. Bugs in helm itself
 
    Fairly rare, but bugs in helm itself might cause failure.
-   
+
 4. Severe bugs in the version of binderhub, jupyterhub or any of the dependencies deployed.
 
    This will usually manifest as a `kubectl rollout` command hanging forever. This is
    caused by a bug in the component that `kubectl rollout` is waiting for constantly
-   crashing, unable to stay up. 
-   
+   crashing, unable to stay up.
+
    Looking at what component it is, and perhaps in the logs, would help!
 
 ### Step 2: Validate the deployment
@@ -246,18 +246,18 @@ the helm deployment is complete!
 
 We run the tests in `tests/` with `pytest` to validate that the deployment succeeded.
 These try to be as thorough as possible, simulating the tests a human would do to
-ensure that the site works as required. 
+ensure that the site works as required.
 
-Look at the docstrings in the files under [`tests/`](https://github.com/jupyterhub/mybinder.org-deploy/tree/master/tests) 
-to see what are the tests being run. 
+Look at the docstrings in the files under [`tests/`](https://github.com/jupyterhub/mybinder.org-deploy/tree/master/tests)
+to see what are the tests being run.
 
-If all the tests succeed, we can consider the staging deployment success! 
+If all the tests succeed, we can consider the staging deployment success!
 
 #### What could go wrong?
 
 1. Bugs in the version of binderhub or jupyterhub deployed, causing any of the tests
    in `tests/` to fail.
-   
+
    The output should tell you which test fails. You can look at the docstring for the
    failing test to understand what it is was testing, and debug from there.
 
diff --git a/docs/source/getting_started/production_environment.md b/docs/source/getting_started/production_environment.md
index 28cefa132..d9ac64693 100644
--- a/docs/source/getting_started/production_environment.md
+++ b/docs/source/getting_started/production_environment.md
@@ -57,7 +57,7 @@ cordoning that node should result in it being drained and reclaimed
 after the max-pod-age lifetime limit
 which often wouldn't happen without manual intervention.
 
-It is still *not quite true* that only user pods are running on the user nodes at this point.
+It is still _not quite true_ that only user pods are running on the user nodes at this point.
 There can be some pods such as heapster and kube-dns that may run on user nodes,
 and need to be manually removed from the pod after cordoning before the autoscaler will allow culling.
 
@@ -69,7 +69,6 @@ Users and core pods are assigned to their pools via a `nodeSelector` in `config/
 We use a custom label `mybinder.org/node-purpose = core | user`
 to select which node a pod should run on.
 
-
 ## mybinder.org specific extra software
 
 We sometimes want to run additional software for the mybinder deployment that
@@ -116,7 +115,7 @@ dependencies:
     repository: https://prometheus-community.github.io/helm-charts
 ```
 
-This also allows us to pin a *version* of Prometheus, which improves
+This also allows us to pin a _version_ of Prometheus, which improves
 reliability of the site.
 
 ```{note}
@@ -136,7 +135,7 @@ file for each, and we can deploy them all at the same time.
 ## HTTPS configuration for `mybinder.org`
 
 Using HTTPS requires having a signed certificate. BinderHub uses [kube-lego](https://github.com/jetstack/kube-lego),
-a tool that obtains and deploys a free *Let's Encrypt* certificate automatically.
+a tool that obtains and deploys a free _Let's Encrypt_ certificate automatically.
 This section describes how to use `kube-lego` to configure and deploy HTTPS support.
 
 `kube-lego` provides 90 day SSL certificates for `mybinder.org` through
@@ -150,7 +149,7 @@ account to use for letsencrypt certification.
 
 Once we have a letsencrypt account set up, we need to attach the SSL
 certificate to a particular `ingress` object. This is a Kubernetes object
-that controls how traffic is routed *into* the deployment. This is also
+that controls how traffic is routed _into_ the deployment. This is also
 done with the `mybinder.org` Helm Chart ([see here for example](https://github.com/jupyterhub/mybinder.org-deploy/blob/5aa6dde60c9b5f3012686f9ba2b23b176c19b224/mybinder/values.yaml#L13)).
 
 Note that letsencrypt will send you an email if your SSL certificate is
@@ -177,7 +176,7 @@ Traffic for `ovh.mybinder.org` is redirected with a CNAME on `binder.mybinder.ov
 Since we use this repo for deployment, it needs credentials for things like our
 google cloud account, and secret tokens for our helm charts. Since this is a
 public repo, we don't want these credentials to be readable in public! To solve
-this, we use [git-crypt][] to store *encrypted* versions of files that should
+this, we use [git-crypt][] to store _encrypted_ versions of files that should
 be kept secret. These files are in the `secrets` folder. `git-crypt` uses a
 shared secret to encrypt and decrypt files. For automated deployments, Travis
 has access to the git-crypt secret in an encrypted environment variable. If you
@@ -186,9 +185,7 @@ or to see the contents of the secret files. When you clone, you will just have
 the opaque, encrypted files. If you need access to view or edit the encrypted
 files, you will need the git-crypt secret. See below for a procedure to share
 the secret. Once you have unlocked the repo with `git-crypt`, you will be able
-to view and edit the encrypted files as if they were any other file. `git-
-crypt` handles the encryption and decryption transparently via git filters.
-
+to view and edit the encrypted files as if they were any other file. `git- crypt` handles the encryption and decryption transparently via git filters.
 
 ### Sharing secrets
 
@@ -201,8 +198,7 @@ ssh-vault. On mac, these are both available from homebrew:
 
     brew install git-crypt ssh-vault
 
-To encrypt the key with ssh-vault, pipe the key file through `ssh-vault
-create`. Assuming you are in a mybinder.org-deploy directory that is already
+To encrypt the key with ssh-vault, pipe the key file through `ssh-vault create`. Assuming you are in a mybinder.org-deploy directory that is already
 setup with git-crypt:
 
 ```bash
@@ -263,7 +259,6 @@ creating files:
 [receiver] $ pbpaste | ssh-vault view | git-crypt unlock -
 ```
 
-
 ### Who has the keys?
 
 People who currently have the git-crypt secret include:
@@ -278,11 +273,10 @@ People who currently have the git-crypt secret include:
 - @arnim
 - @MridulS
 - @callummole
-- *add yourself here if you have it*
+- _add yourself here if you have it_
 
 Contact one of them if you need access to the git-crypt key.
 
-
 [mybinder.org-deploy]: https://github.com/jupyterhub/mybinder.org-deploy
 [prod]: https://mybinder.org
 [mybinder.org]: https://mybinder.org
@@ -290,7 +284,7 @@ Contact one of them if you need access to the git-crypt key.
 [staging]: https://staging.mybinder.org
 [binderhub]: https://github.com/jupyterhub/binderhub
 [`jupyterhub/binderhub`]: https://github.com/jupyterhub/binderhub
-[BinderHub documentation]: https://binderhub.readthedocs.io/en/latest/
+[binderhub documentation]: https://binderhub.readthedocs.io/en/latest/
 [repo2docker]: https://github.com/jupyterhub/repo2docker
 [git-crypt]: https://github.com/AGWA/git-crypt
 [ssh-vault]: https://github.com/ssh-vault/ssh-vault
diff --git a/docs/source/incident-reports/2017-09-29-504.md b/docs/source/incident-reports/2017-09-29-504.md
index d946e7b2b..bcbb169a7 100644
--- a/docs/source/incident-reports/2017-09-29-504.md
+++ b/docs/source/incident-reports/2017-09-29-504.md
@@ -50,14 +50,12 @@ Additionally, there were several errors related to the reflector connection, whi
     urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='x.x.x.x', port=443): Max retries exceeded with url: /api/v1/namespaces/beta/pods?labelSelector=heritage%3Djupyterhub%2Ccomponent%3Dsingleuser-server (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fd666225748>: Failed to establish a new connection: [Errno 111] Connection refused',))
 ```
 
-
 ### 14:10
 
 hub pod is relaunched to clear invalid state.
 Service is back to normal, though no actual fixes have been applied.
 The same issue is expected to return.
 
-
 ## Action Items
 
 ### BinderHub
@@ -71,11 +69,11 @@ The same issue is expected to return.
 ### KubeSpawner
 
 1. Fix known issue of PodReflector missing events
-   [Pull Request]( https://github.com/jupyterhub/kubespawner/pull/81).
+   [Pull Request](https://github.com/jupyterhub/kubespawner/pull/81).
 2. Investigate further possibilities of reflector failure and recovery
    [Issue](https://github.com/jupyterhub/kubespawner/issues/85)
 3. Unrecoverable PodReflector errors should abort the Hub
-   [Pull Request]( https://github.com/jupyterhub/kubespawner/pull/86).
+   [Pull Request](https://github.com/jupyterhub/kubespawner/pull/86).
 
 The primary cause of these issues is the loss of events on the KubeSpawner PodReflector.
 https://github.com/jupyterhub/kubespawner/pull/81 fixes at least one known case.
diff --git a/docs/source/incident-reports/2017-11-30-oom-proxy.md b/docs/source/incident-reports/2017-11-30-oom-proxy.md
index 4e94b72ff..30db648a9 100644
--- a/docs/source/incident-reports/2017-11-30-oom-proxy.md
+++ b/docs/source/incident-reports/2017-11-30-oom-proxy.md
@@ -1,28 +1,34 @@
 # 2017-11-30 4:23PM PST, OOM (Out of Memory) Proxy
 
 ## Summary
-Tim and Chris noticed at 0:59 CET (need to convert to PST) that mybinder.org showed an error that creating temporary users failed when launching a new server. This was noticed because Tim happened to look at grafana. One node running a proxy had run out of memory which broke the proxy. Probably a build container had used up all the memory on the node as builds had no memory limits enforced.
 
+Tim and Chris noticed at 0:59 CET (need to convert to PST) that mybinder.org showed an error that creating temporary users failed when launching a new server. This was noticed because Tim happened to look at grafana. One node running a proxy had run out of memory which broke the proxy. Probably a build container had used up all the memory on the node as builds had no memory limits enforced.
 
 ## Timeline
 
 ### 2017-11-30 16:22 PST
+
 Node runs out of memory, service starts degrading.
 
 ### 16:59 PST
+
 Investigation starts after noticing grafana looks weird. Error message when launching a new server:
+
 ```
 Found built image, launching...
 Launching server...
 Failed to create temporary user for gcr.io/binder-prod/r2d-fd74043wildtreetech-explore-open-data
 :6be6d6329de99168d0a0b68f9d52228ecc61ac50
 ```
+
 Confirmed by Tim and Chris.
 
 ### 17:02 PST
+
 Suggestion that it might be related to https://status.cloud.google.com/incident/storage/17006. All nodes show status "Ready" on "Kubernetes clusters" page of cloud console.
 
 ### 17:04 PST
+
 Chris reports that proxy pods are in CrashloopBackoff state and had been restarted ~13 times. A kubectl describe on the pod gave:
 
 ```
@@ -43,54 +49,65 @@ and
   Warning  Unhealthy              9s                 kubelet, gke-prod-a-default-pool-6ab3d8ec-0h28  Readiness probe failed: Get http://10.12.5.36:10254/healthz: dial tcp 10.12.5.36:10254: getsockopt: connection refused
   Warning  BackOff                5s (x5 over 33s)   kubelet, gke-prod-a-default-pool-6ab3d8ec-0h28  Back-off restarting failed container
   Warning  FailedSync             5s (x5 over 33s)   kubelet, gke-prod-a-default-pool-6ab3d8ec-0h28  Error syncing pod
-  ```
+```
 
 and logs gave:
 
 `Error from server (BadRequest): a container name must be specified for pod proxy-fd9c4f59b-pjhth, choose one of: [nginx chp]`
 
 ### 17:07
+
 Tim asks if "some of them are still running?". Chris says that pods are running but no new ones are being created.
 
 ### 17:09
+
 jupyterhub pod shows lots of DELETE requests that are timing out and tracebacks. Tim suggests restarting jupyterhub pod.
 
 ### 17:12
+
 Tim asks how to contact Yuvi. Tim restarts jhub pod with `kubectl get pod hub-deployment-944c6474c-22sjh -n prod -o yaml | kubectl replace --force -f -`
 This restarts the jupyterhub, removes all user pods, error persists.
 
 ### 17:14
+
 Chris runs `kubectl describe` on the node on which the proxy runs which gives:
+
 ```
 Warning OOMKilling 58m kernel-monitor, gke-prod-a-default-pool-6ab3d8ec-0h28 Memory cgroup out of memory: Kill process 8339 (python) score 1576 or sacrific
 ```
 
 ### 17:18
+
 Chris suggests to try cordoning the OOM node and then deleting the proxy pod.
 
 ### 17:20
+
 Chris notices that proxy pod is working again. Service appears to be restored. proxy pod had been running for 10m already by this point (since ~15:10). Chris uncordons node again.
 
 ### 17:21 PST
-Service is restored, user pods start running again.
 
+Service is restored, user pods start running again.
 
 ## Action items
 
 ### Repo2docker
+
 Limit memory available to build pods. (https://github.com/jupyterhub/repo2docker/pull/159)
 
 ### Jupyterhub
+
 Fix configuration so that user pods are not cleaned up when jupyterhub pod restarts (https://github.com/jupyterhub/mybinder.org-deploy/issues/198)
 
 ### Process
+
 1. Should nominate one person to be the driver, maybe a shared terminal. So that only one person is issuing commands to change the state of the cluster and the other person knows about them.
 2. Better alerting for when something is wrong with the cluster. This one could have been alerted by counting 4xx responses on the jupyterhub pod.
 
 ## Logs
 
 Trying to collect to gather logs looked at during the incident:
-* https://hackmd.io/JwBgjAhgTARgHAZgLRjlMSAsBjCB2JGAEzwiTgFYwKBTNANnoDNwg===?edit (bhub pod log starting from before the problem was noticed)
-* https://console.cloud.google.com/logs/viewer?project=binder-prod&minLogLevel=0&expandAll=false&timestamp=2017-11-30T23%3A22%3A18.000000000Z&resource=container%2Fcluster_name%2Fprod-a%2Fnamespace_id%2Fprod&advancedFilter=resource.type%3D%22container%22%0Aresource.labels.pod_id%3D%22prod-nginx-ingress-controller-7b4fdbdcc8-qp6jk%22%0Aresource.labels.zone%3D%22us-central1-a%22%0Aresource.labels.project_id%3D%22binder-prod%22%0Aresource.labels.cluster_name%3D%22prod-a%22%0Aresource.labels.container_name%3D%22nginx-ingress-controller%22%0Aresource.labels.namespace_id%3D%22prod%22%0Aresource.labels.instance_id%3D%224874803091664833146%22%0Atimestamp%3D%222017-11-30T23%3A22%3A18.000000000Z%22%0AinsertId%3D%221xxo64cg1cnzk5b%22 weird things start showing up in the log around here
-* gitter chat log https://gitter.im/jupyterhub/binder?at=5a209b75ffa3e37919df1c15
-* grafana screenshots https://github.com/jupyterhub/binder/issues/39
+
+- https://hackmd.io/JwBgjAhgTARgHAZgLRjlMSAsBjCB2JGAEzwiTgFYwKBTNANnoDNwg===?edit (bhub pod log starting from before the problem was noticed)
+- https://console.cloud.google.com/logs/viewer?project=binder-prod&minLogLevel=0&expandAll=false&timestamp=2017-11-30T23%3A22%3A18.000000000Z&resource=container%2Fcluster_name%2Fprod-a%2Fnamespace_id%2Fprod&advancedFilter=resource.type%3D%22container%22%0Aresource.labels.pod_id%3D%22prod-nginx-ingress-controller-7b4fdbdcc8-qp6jk%22%0Aresource.labels.zone%3D%22us-central1-a%22%0Aresource.labels.project_id%3D%22binder-prod%22%0Aresource.labels.cluster_name%3D%22prod-a%22%0Aresource.labels.container_name%3D%22nginx-ingress-controller%22%0Aresource.labels.namespace_id%3D%22prod%22%0Aresource.labels.instance_id%3D%224874803091664833146%22%0Atimestamp%3D%222017-11-30T23%3A22%3A18.000000000Z%22%0AinsertId%3D%221xxo64cg1cnzk5b%22 weird things start showing up in the log around here
+- gitter chat log https://gitter.im/jupyterhub/binder?at=5a209b75ffa3e37919df1c15
+- grafana screenshots https://github.com/jupyterhub/binder/issues/39
diff --git a/docs/source/incident-reports/2018-01-04-failed-staging-deploy.md b/docs/source/incident-reports/2018-01-04-failed-staging-deploy.md
index e5aab2076..5e846f450 100644
--- a/docs/source/incident-reports/2018-01-04-failed-staging-deploy.md
+++ b/docs/source/incident-reports/2018-01-04-failed-staging-deploy.md
@@ -1,4 +1,3 @@
-
 # 2018-01-04, Failed deploy to staging
 
 ## Summary
@@ -19,11 +18,11 @@ PR [#254](https://github.com/jupyterhub/mybinder.org-deploy/pull/254) failed to
 
 [Travis CI](https://travis-ci.org/jupyterhub/mybinder.org-deploy/builds/325095814) errored and displayed that the deploy to staging failed.
 
-PR #254 was generated using the first set of instructions in the `README`, [Deploying a Change](https://github.com/jupyterhub/mybinder.org-deploy#deploying-a-change). *Note: User error was made here by assuming the SHA used in the BinderHub helm-chart (binderhub-0.1.0-441f5ea) was the same as the PR in the BinderHub merge commit (4e3bafb). The assumption was that Travis would deploy the binderhub change to the helm-chart repo using the merge commit hash. The Documentation in the `README `'s [BinderHub](https://github.com/jupyterhub/mybinder.org-deploy#binderhub) section has this correct, but the user didn't think to scroll down as they had done the deployment process before but not on a regular basis.*
+PR #254 was generated using the first set of instructions in the `README`, [Deploying a Change](https://github.com/jupyterhub/mybinder.org-deploy#deploying-a-change). _Note: User error was made here by assuming the SHA used in the BinderHub helm-chart (binderhub-0.1.0-441f5ea) was the same as the PR in the BinderHub merge commit (4e3bafb). The assumption was that Travis would deploy the binderhub change to the helm-chart repo using the merge commit hash. The Documentation in the `README `'s [BinderHub](https://github.com/jupyterhub/mybinder.org-deploy#binderhub) section has this correct, but the user didn't think to scroll down as they had done the deployment process before but not on a regular basis._
 
 Investigation begins.
 
-### 08:17 
+### 08:17
 
 Following the process in the `README`, I reverted the original PR since Travis showed an error. PR [#255](https://github.com/jupyterhub/mybinder.org-deploy/pull/255) reverted #254.
 
@@ -41,7 +40,6 @@ Message posted on Gitter to understand why the merge SHA (4e3bafb) was not found
 
 From the Gitter response, user learned that there is a delay in the helm-chart showing up. User realizes that I also made an incorrect assumption about the hash to use in the PR for binderhub helm-chart. The correct SHA to use would be the last commit where the relevant files changed (441f5ea) which is not the same as the most recent commit (4e3bafb).
 
-
 ### 08:59
 
 Submitted a new PR [#256](https://github.com/jupyterhub/mybinder.org-deploy/pull/256) to staging with the correct hash. Travis deploys successfully to staging. Visual review of `staging.mybinder.org` site looks fine.
@@ -54,7 +52,6 @@ Tested repo, `willingc/ThinkDSP`, using the prod service to see if the notebook
 
 Everything is fine and prod is working.
 
-
 ## Action items
 
 ### Process
diff --git a/docs/source/incident-reports/2018-01-17-ubuntu-upgrade.md b/docs/source/incident-reports/2018-01-17-ubuntu-upgrade.md
index 8be27ac24..2d4dd72ca 100644
--- a/docs/source/incident-reports/2018-01-17-ubuntu-upgrade.md
+++ b/docs/source/incident-reports/2018-01-17-ubuntu-upgrade.md
@@ -1,7 +1,5 @@
-
 # 2018-01-17, Emergency Aardvark bump
 
-
 ## Summary
 
 In the midst of a general Travis period of instability, we were slow to
@@ -10,7 +8,7 @@ repository we were using in the base image for repo2docker. This meant that
 most Binders would fail to build because those packages were no longer available.
 We had to [perform an emergency bump](https://github.com/jupyterhub/repo2docker/pull/197)
 to the latest version of Ubuntu (artful).
-In the future we should keep bumping when ubuntu makes a new release *until*
+In the future we should keep bumping when ubuntu makes a new release _until_
 it makes a new LTS release, then we should pin repo2docker at that.
 
 ## Timeline
@@ -18,6 +16,7 @@ it makes a new LTS release, then we should pin repo2docker at that.
 All times in PST
 
 ### 2018-01-15
+
 General Travis failures happening due to Travis downtime (not related to
 Binder deployment)
 
@@ -29,10 +28,12 @@ was dismissed as holdover from Travis failing on the 15th (since it was reported
 as 'no route to host' rather than 404).
 
 ### 2018-01-17 17:14pm
-* Other travis failures (berkeley's), points to issue being real
-* Realization this will cause repo2docker + mybinder to fail
+
+- Other travis failures (berkeley's), points to issue being real
+- Realization this will cause repo2docker + mybinder to fail
 
 ### 2018-01-17 17:30pm
+
 Binder build logs showed lots of "IGN" errors, due to trying to pull from
 zesty repositories. Then would fail.
 
@@ -41,27 +42,30 @@ a long-term release. The base Binder image was using zesty, so it would look
 for packages that weren't there anymore.
 
 ### 18:57
-Bump to artful, merged + deployed. Checked mybinder.org and problem was resolved.
 
+Bump to artful, merged + deployed. Checked mybinder.org and problem was resolved.
 
 ### 19:00
-Tweet + Email listserv announcing bump to Artful.
 
+Tweet + Email listserv announcing bump to Artful.
 
 ## Action items
 
 ### Process
 
-* Note that Ubuntu non-LTS is on a ~9 month cycle, not the 1 year cycle we assumed.
+- Note that Ubuntu non-LTS is on a ~9 month cycle, not the 1 year cycle we assumed.
   Keep bumping Ubuntu versions until we hit LTS, then stop [Issue](https://github.com/jupyterhub/repo2docker/issues/198)
-* Subscribe to the ubuntu-announce mailing list [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/296)
+- Subscribe to the ubuntu-announce mailing list [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/296)
 
 ### repo2docker
-* Separate python version from distro version [Issue](https://github.com/jupyterhub/repo2docker/issues/185)
-* Allow users to pin distros (with an apt.yaml) [PR](https://github.com/jupyterhub/repo2docker/pull/148)
+
+- Separate python version from distro version [Issue](https://github.com/jupyterhub/repo2docker/issues/185)
+- Allow users to pin distros (with an apt.yaml) [PR](https://github.com/jupyterhub/repo2docker/pull/148)
 
 ### Misc
-* Keep our own apt mirror [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/295)
+
+- Keep our own apt mirror [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/295)
 
 ### mybinder.org-deploy
-* Continuous tests should be run against binder, to tell us when things fail [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/19)
+
+- Continuous tests should be run against binder, to tell us when things fail [Issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/19)
diff --git a/docs/source/incident-reports/2018-01-18-reddit-hug.md b/docs/source/incident-reports/2018-01-18-reddit-hug.md
index 956f73658..73380b623 100644
--- a/docs/source/incident-reports/2018-01-18-reddit-hug.md
+++ b/docs/source/incident-reports/2018-01-18-reddit-hug.md
@@ -5,7 +5,6 @@
 A repo is posted to [reddit /r/python](https://www.reddit.com/r/Python/comments/7r6e6w/visualize_your_mostplayed_artists_tracks_and/), it starts getting popular. Traffic starts
 building from around 6pm. Peaks at about 6am with 600 running pods.
 
-
 ## Timeline
 
 All times in PST
@@ -81,10 +80,12 @@ Note that jupyterhub logs are full of errors. Reading logs leads to conclusion t
 ### 8:39
 
 Checking network connectivity between jupyterhub pod and a random pod. "ssh" into the hub pod with `kubectl --namespace=prod exec -it hub-7649b9bf8-d769g /bin/bash` and attempt to access a random user pod found with `kubectl --namespace=prod get pod -o wide`. Test network connectivity with:
+
 ```python
 >>> requests.get('http://10.12.6.136:8888/')
 <Response [404]>
 ```
+
 404 error means we managed to talk to the jupyter notebook server on that IP.
 
 ### 8:47
@@ -116,7 +117,6 @@ Decide to cordon off node: `kubectl cordon gke-prod-a-ssd-pool-972e4826-2fhq`. N
 
 After testing several repositories by hand and with `py.test tests/test_launch.py --hub-url=https://hub.mybinder.org --binder-url=https://mybinder.org` feeling is things are back to working order. Brief discussion if incident is over or not.
 
-
 ## Action items
 
 ### Process
@@ -124,7 +124,6 @@ After testing several repositories by hand and with `py.test tests/test_launch.p
 - Gather commands used in incident response and add to SRE guide.
 - Discuss how to know when to call an incident as resolved.
 
-
 ### Training
 
 - Investigate k8 training
diff --git a/docs/source/incident-reports/2018-01-18-ssl-outdated.md b/docs/source/incident-reports/2018-01-18-ssl-outdated.md
index 2548043b2..95dacb63b 100644
--- a/docs/source/incident-reports/2018-01-18-ssl-outdated.md
+++ b/docs/source/incident-reports/2018-01-18-ssl-outdated.md
@@ -1,4 +1,3 @@
-
 # 2018-01-11, Warning from letsencrypt about outdated SSL certificate
 
 ## Summary
@@ -20,7 +19,6 @@ All times in PST
 A team member received an email that our SSL for `beta.mybinder.org` was going to expire.
 He opened https://github.com/jupyterhub/mybinder.org-deploy/issues/283.
 
-
 ### 2018-01-18
 
 Another team member used the SSL certificate checking website below:
@@ -61,7 +59,7 @@ is what is triggering the emails, but our new account is working fine.
 
 - Do not use a single team member's email address for letsencrypt
 - Instead, use a shared google groups email account so we all get pinged
-  * This has been done: binder-team@googlegroups.com
+  - This has been done: binder-team@googlegroups.com
 - keep an eye on the SSL once the first expiration date comes around and make sure
   this is a correct assumption.
 
diff --git a/docs/source/incident-reports/2018-02-12-launch-fail.md b/docs/source/incident-reports/2018-02-12-launch-fail.md
index 26f05669a..d18c0162e 100644
--- a/docs/source/incident-reports/2018-02-12-launch-fail.md
+++ b/docs/source/incident-reports/2018-02-12-launch-fail.md
@@ -18,7 +18,7 @@ proceed further. Eventually it'd return a "your image took too long to launch" e
 ### 2018-02-12 14:06
 
 From the [grafana board](https://grafana.mybinder.org), we realized that in the
-"Launch Times Summary" plot we showed *all* pods as failing to launch.
+"Launch Times Summary" plot we showed _all_ pods as failing to launch.
 
 ### 14:08
 
@@ -33,21 +33,20 @@ shows successful "Launch Times Summary" data.
 
 ### What went well
 
-* Once we noted the problem, it was quickly resolved.
+- Once we noted the problem, it was quickly resolved.
 
 ### What went wrong
 
-* The outage was present for nearly an hour before we noticed it. This is partially
+- The outage was present for nearly an hour before we noticed it. This is partially
   because the site itself was returning no errors, only taking forever to launch.
 
 ### Where we got lucky
 
-* The solution was just "delete `binder` and `hub`" and the problem resolved
+- The solution was just "delete `binder` and `hub`" and the problem resolved
   itself.
 
 ## Action items
 
-
 ### Process improvements
 
 1. Improve the team operations around debugging the cluster more generally. We
diff --git a/docs/source/incident-reports/2018-02-20-jupyterlab-announcement.md b/docs/source/incident-reports/2018-02-20-jupyterlab-announcement.md
index da5370fdc..da2ba804e 100644
--- a/docs/source/incident-reports/2018-02-20-jupyterlab-announcement.md
+++ b/docs/source/incident-reports/2018-02-20-jupyterlab-announcement.md
@@ -5,7 +5,6 @@
 The JupyterLab [announcement post](https://blog.jupyter.org/jupyterlab-is-ready-for-users-5a6f039b8906) drove a great deal of traffic to mybinder.org.
 This caused several outages throughout the day from varying causes.
 
-
 We prepared for this by temporarily increasing the mininum number of nodes.
 
 After a deployment, most users were getting "Failed to create temporary user for gcr.io/binder-prod/" when attempting to launch their image. This was caused by a small bug that manifests only when large numbers of users are using Binder at the same time. The bug was identified and fixed, but due to logistical issues it caused mybinder to be unusable for about 1h50m, and unstable for ~1 day.
@@ -38,7 +37,6 @@ due to the per-repo limit. The rate limit is behaving as intended.
 [Action Item] launches that are rejected due to rate limiting are registered as a
 'failed launch' in our launch success metric. This should instead be its own label.
 
-
 ### 15:10
 
 [PR #428](https://github.com/jupyterhub/mybinder.org-deploy/pull/428) increases the per-repo limit to 500.
@@ -82,7 +80,7 @@ Grafana pod dies and is restarted multiple times. This time by Kubernetes withou
 
 ### 16:00
 
-JupyterLab has hit the 500 user limit and is  ?????
+JupyterLab has hit the 500 user limit and is ?????
 After returning to working order, ????
 
 ### 16:05
@@ -95,7 +93,6 @@ Hub is restarted to attempt to clear out bad state via `kubectl delete pod`
 
 The hub comes back and promptly culls many inactive pods. However, there appears to be a problem in the culler itself. Every cull request fails due to 400 requests asking for an already-stopping server to stop again, resulting in the culler exiting. **The culler shouldn't exit when there is an error**
 
-
 ### 16:29
 
 restart both hub and proxy pods
@@ -108,7 +105,6 @@ Everything's still failing. Binder requests to the Hub are failing with a timeou
 [W 180220 15:32:35 web:1588] 500 GET /build/gh/jupyterlab/jupyterlab-demo/18a9793b58ba86660b5ab964e1aeaf7324d667c8 (10.12.8.27): Failed to create temporary user for gcr.io/binder-prod/r2d-fd74043jupyterlab-jupyterlab-demo:18a9793b58ba86660b5ab964e1aeaf7324d667c8
 ```
 
-
 ### 16:33
 
 BinderHub is restarted, in case there is an issue in BinderHub itself.
@@ -117,10 +113,9 @@ After this restart, launches begin to succeed again. It appears that BinderHub w
 
 It could also have been a kubernetes networking issue where pod-networking is no longer working.
 
-
 ### 16:40
 
-Grafana pod restarted itself again. No indication as to why, but it could just be being reassigned to new nodes as the cluster resizes. 
+Grafana pod restarted itself again. No indication as to why, but it could just be being reassigned to new nodes as the cluster resizes.
 
 In hindsight, it is most likely because it only requests 100Mi of RAM and nothing more.
 
@@ -138,7 +133,6 @@ Since BinderHub is reaching a timeout after several requests to the hub have acc
 - install pycurl on binderhub, which has been known to fix some timeout issues on jupyterhub underload
 - revert per-repo limit back to 300 pods
 
-
 ### 18:10
 
 Travis deployment [fails tests on prod](https://travis-ci.org/jupyterhub/mybinder.org-deploy/builds/343924455):
@@ -165,7 +159,6 @@ due to networking failure on a node, but we don't know that yet.
 pycurl PR is reverted due to suspicion that it caused Service Unavailable errors.
 It turns out this is not the case, the Hub really was unavailable due to bad networking state on at least one node.
 
-
 Hub logs show:
 
 ```
@@ -283,23 +276,23 @@ hub. [Response codes for the hub](https://grafana.mybinder.org/render/dashboard-
 
 We have the idea to delete the routing table for the `hub-` pod so that it reduces the HTTP requests. This is done with the following commands.
 
-* First, enter the `hub-` pod and start a python session with:
-  
+- First, enter the `hub-` pod and start a python session with:
+
   `kubectl --namespace=prod exec -it hub-989cc9bd-5qdcb /bin/bash`
-  
+
   then
-  
+
   `python`
 
-* delete default HTTP route:
-   
+- delete default HTTP route:
+
   `requests.delete('http://proxy-api:8001/api/routes//', headers={'Authorization': 'token ' + os.environ['CONFIGPROXY_AUTH_TOKEN']})`
 
-* add route for /hub/api:
+- add route for /hub/api:
 
   `requests.post('http://proxy-api:8001/api/routes//hub/api', headers={'Authorization': 'token ' + os.environ['CONFIGPROXY_AUTH_TOKEN']}, json={'hub': True, 'target': 'http://10.15.251.161:8081', 'jupyterhub': True, 'last_activity': '2018-02-20T21:18:29.579Z'})`
 
-We decide to *not* experiment on live users right now. 
+We decide to _not_ experiment on live users right now.
 Everything has been stable once the 100-users-per-repo
 throttling had been re-established..
 
@@ -329,11 +322,11 @@ This high CPU usage in the Hub due to a flood of threads created by kubernetes-c
 
 ## Conclusions
 
-The ultimate cause of this incident was a bug in a specific version JupyterHub+KubeSpawner+kubernetes-client that causes unreasonably high load for a moderate load. This bug had been fixed weeks ago in the jupyterhub chart, and was present. BinderHub was using a development version of the jupyterhub chart *prior* to the latest stable release.
+The ultimate cause of this incident was a bug in a specific version JupyterHub+KubeSpawner+kubernetes-client that causes unreasonably high load for a moderate load. This bug had been fixed weeks ago in the jupyterhub chart, and was present. BinderHub was using a development version of the jupyterhub chart _prior_ to the latest stable release.
 
 1. deploying a capacity increase during heavy load may not be a recipe for success, but this is inconclusive.
 1. handling of slow shutdown needs work in jupyterhub
-1. there is a bug in jupyterhub causing it to attempt to delete routes from the proxy that are not there. The resulting 404 is already fixed in jupyterhub, but the bug causing the incorrect *attempt* is still undiagnosed.
+1. there is a bug in jupyterhub causing it to attempt to delete routes from the proxy that are not there. The resulting 404 is already fixed in jupyterhub, but the bug causing the incorrect _attempt_ is still undiagnosed.
 1. grafana is regularly being restarted, which causes the page to be down. Since deployments now notify grafana of a deploy, this can prevent deploy success. It is a harmless failure in this case because if the grafana annotation fails, no deploy stages are attempted, so a Travis retry is quite safe.
 1. culler has an issue where it exits if its request fails with 400
 1. culler shouldn't be making requests that fail with 400
@@ -342,16 +335,14 @@ The ultimate cause of this incident was a bug in a specific version JupyterHub+K
    new users not being created.
 1. Unclear if this instability was fixed by deleting `binder-`, or if this was just waiting for a
    change to propagate.
-   
 1. JupyterHub was basically getting swamped because it was handling more HTTP requests by an order of magnitude or more. This was because of a few factors:
-    1. The aforementioned big bump in usage
-    2. The "default" route points to the hub, so when a user's pod would get delete and they'd continue doing stuff, all resulting requests went to the hub.
-    3. We don't have a mechanism for throttling requests on the hub
-    4. We only have a single hub that's handling all HTTP requests
-    5. There were cascading effects going on where errors would generate more HTTP requests that would worsen the problem.
+   1. The aforementioned big bump in usage
+   2. The "default" route points to the hub, so when a user's pod would get delete and they'd continue doing stuff, all resulting requests went to the hub.
+   3. We don't have a mechanism for throttling requests on the hub
+   4. We only have a single hub that's handling all HTTP requests
+   5. There were cascading effects going on where errors would generate more HTTP requests that would worsen the problem.
 1. some issues may have been attributable to unhealthy nodes, but diagnosing unhealthy nodes is difficult.
 
-
 ## Action Items
 
 ### JupyterHub
@@ -361,7 +352,6 @@ The ultimate cause of this incident was a bug in a specific version JupyterHub+K
 - Investigating allowing deletion of users whose servers are slow to stop or fail to stop altogether https://github.com/jupyterhub/jupyterhub/issues/1677
 - implement API-only mode for use cases like Binder (https://github.com/jupyterhub/jupyterhub/issues/1675)
 
-
 ### Zero-to-JupyterHub
 
 cull_idle_servers:
@@ -373,7 +363,7 @@ cull_idle_servers:
 
 - ensure pycurl is used, which is known to perform better with large numbers of requests than tornado's default SimpleAsyncHTTPClient (https://github.com/jupyterhub/binderhub/pull/460)
 - Investigate timeout issue, which may be due to lack of pycurl, too many concurrent requests, or purely the overloaded Hub (https://github.com/jupyterhub/binderhub/issues/464)
-- separate rejection code/metadata for launch failures due to repo limit vs. "regular" launch failures. Note: on investigation, we already do this so launch failures should *not* include rejected launches.
+- separate rejection code/metadata for launch failures due to repo limit vs. "regular" launch failures. Note: on investigation, we already do this so launch failures should _not_ include rejected launches.
 - Figure out if there's a way to reduce the number of HTTP requests that are going to the JupyterHub (this became a problem w/ high load) (https://github.com/jupyterhub/binderhub/pull/461)
 - Make it possible for Binder to launch multiple JupyterHubs and direct users through those hubs in a round-robin fashion (https://github.com/jupyterhub/binderhub/issues/465)
 
diff --git a/docs/source/incident-reports/2018-02-22-nginx-down.md b/docs/source/incident-reports/2018-02-22-nginx-down.md
index 3f195c0e4..5e27519f2 100644
--- a/docs/source/incident-reports/2018-02-22-nginx-down.md
+++ b/docs/source/incident-reports/2018-02-22-nginx-down.md
@@ -50,7 +50,6 @@ Confirm that the problem is resolved, grafana/mybinder.org are now back.
 
 1. Make sure that everybody gets emailed when the site goes down (DONE)
 
-
 ### Technical improvements
 
 1. Find a path forward to switch away from NGINX to better traffic tech [#528](https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/528)
diff --git a/docs/source/incident-reports/2018-03-13-PVC-hub-locked.md b/docs/source/incident-reports/2018-03-13-PVC-hub-locked.md
index 9706c5728..0fd7c1645 100644
--- a/docs/source/incident-reports/2018-03-13-PVC-hub-locked.md
+++ b/docs/source/incident-reports/2018-03-13-PVC-hub-locked.md
@@ -1,7 +1,9 @@
 # 2018-03-13, PVC for hub is locked
 
 ## Questions for follow up
-*
+
+-
+
 ## Summary
 
 After a few hours we noticed that JupyterHub wasn't
@@ -21,35 +23,33 @@ All times in CET
 
 Problem is identified
 
-* mybinder launch success rate has been at zero for several hours now [https://grafana.mybinder.org/dashboard/db/main-dashboard?refresh=1m&orgId=1&panelId=17&fullscreen&from=1520900905664&to=1520922505664](https://grafana.mybinder.org/dashboard/db/main-dashboard?refresh=1m&orgId=1&panelId=17&fullscreen&from=1520900905664&to=1520922505664)
-* lots of pods are in state "Unknown" and "NodeLost"
-* pods in weird states are on at least these nodes `10.128.0.7` `10.128.0.5`
+- mybinder launch success rate has been at zero for several hours now [https://grafana.mybinder.org/dashboard/db/main-dashboard?refresh=1m&orgId=1&panelId=17&fullscreen&from=1520900905664&to=1520922505664](https://grafana.mybinder.org/dashboard/db/main-dashboard?refresh=1m&orgId=1&panelId=17&fullscreen&from=1520900905664&to=1520922505664)
+- lots of pods are in state "Unknown" and "NodeLost"
+- pods in weird states are on at least these nodes `10.128.0.7` `10.128.0.5`
 
 ### 07:33
 
 Attempts to cordon bad nodes to see if this helps things.
 
-* `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-n2sk` and `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-6`hmq
-* the hub pod (`hub-65d9f46698-dj4jb`) was in state `Unknown` and a second hub pod (`hub-65d9f46698-dmlcv`) in `ContainerCreating` since 5h -> deleted both to see if this reschedules them on a healthy node
+- `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-n2sk` and `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-6`hmq
+- the hub pod (`hub-65d9f46698-dj4jb`) was in state `Unknown` and a second hub pod (`hub-65d9f46698-dmlcv`) in `ContainerCreating` since 5h -> deleted both to see if this reschedules them on a healthy node
 
 ### 07:39
 
-* bhub pod can't talk to the jhub pod, but it can connect to google.com and github.com
-* starting a new jhub pod is failing because the PVC is still claimed by another old pod, presumably that old pod is dead/lost in action and hence not releasing the claim
+- bhub pod can't talk to the jhub pod, but it can connect to google.com and github.com
+- starting a new jhub pod is failing because the PVC is still claimed by another old pod, presumably that old pod is dead/lost in action and hence not releasing the claim
 
 ### 07:59
 
-* manually deleted all pods on node `-n2sk`, will this help the node to release the PVC?
-    * (it does not)
-* manually reset `gke-prod-a-ssd-pool-32-134a959a-n2sk` in the hope that this will force the release of the PVC. This is done in the GCP web user-interface
-
+- manually deleted all pods on node `-n2sk`, will this help the node to release the PVC?
+  - (it does not)
+- manually reset `gke-prod-a-ssd-pool-32-134a959a-n2sk` in the hope that this will force the release of the PVC. This is done in the GCP web user-interface
 
 ### 08:05
 
-* `hub-65d9f46698-454cf` is now pulling its docker image, scheduled on `gke-prod-a-ssd-pool-32-134a959a-1j33`
-* pod successfully scheduled and launched. running again, and the `binder-examples/r` repo successfully launches
-* persistent plot of launch success rate dropping to zero https://grafana.mybinder.org/render/dashboard-solo/db/main-dashboard?refresh=1m&orgId=1&from=1520881680522&to=1520924880522&panelId=17&width=1000&height=500&tz=UTC%2B01%3A00
-
+- `hub-65d9f46698-454cf` is now pulling its docker image, scheduled on `gke-prod-a-ssd-pool-32-134a959a-1j33`
+- pod successfully scheduled and launched. running again, and the `binder-examples/r` repo successfully launches
+- persistent plot of launch success rate dropping to zero https://grafana.mybinder.org/render/dashboard-solo/db/main-dashboard?refresh=1m&orgId=1&from=1520881680522&to=1520924880522&panelId=17&width=1000&height=500&tz=UTC%2B01%3A00
 
 ### 08:11
 
@@ -57,8 +57,8 @@ General cleanup because many pods are not identified by k8s. Deleting all pods i
 
 ### 08:17
 
-* deleting pods in Unknown state does not seem to do anything. Pods remain listed.
-* we assume the reason the pod is marked as "Unknown" is because k8s can't find out anything about it, which explains why it can't delete it. We will have to investigate what to do about those pods. Restarting the node seems to remove them but that feels pretty heavy handed
+- deleting pods in Unknown state does not seem to do anything. Pods remain listed.
+- we assume the reason the pod is marked as "Unknown" is because k8s can't find out anything about it, which explains why it can't delete it. We will have to investigate what to do about those pods. Restarting the node seems to remove them but that feels pretty heavy handed
 
 ### 13:32
 
@@ -103,8 +103,8 @@ We discover that another node has entered "NodeLost" state. Grafana and Promethe
 
 Run:
 
-* `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-bmsw`
-* `deleting all pods on the lost node, w/ state "NodeLost" or "Unknown"`
+- `kubectl cordon gke-prod-a-ssd-pool-32-134a959a-bmsw`
+- `deleting all pods on the lost node, w/ state "NodeLost" or "Unknown"`
 
 The grafana/prometheus pods that were _trying_ to start before still didn't (they had been in that state for many hours) so we deleted those pods to see if new ones worked.
 
diff --git a/docs/source/incident-reports/2018-03-26-no-space-left.md b/docs/source/incident-reports/2018-03-26-no-space-left.md
index f6cef0325..462c8b9f2 100644
--- a/docs/source/incident-reports/2018-03-26-no-space-left.md
+++ b/docs/source/incident-reports/2018-03-26-no-space-left.md
@@ -34,7 +34,6 @@ Both of the cordoned nodes were aged 5-6 days and were the oldest nodes in the c
 I suspect that node age is related to this, and we will see it every week or so as something accumulates on the nodes.
 The root cause is still unknown.
 
-
 ## Lessons learned
 
 ### What went well
@@ -49,7 +48,6 @@ The root cause is still unknown.
 - Binder was unavailable, but nobody was notified.
   Only proactive checking of Binder status on Grafana revealed the issue.
 
-
 ## Action items
 
 - [x] Add log metric for "no space left on device" messages that seem correlated with problematic nodes
diff --git a/docs/source/incident-reports/2018-03-31-server-start-fail.md b/docs/source/incident-reports/2018-03-31-server-start-fail.md
index c9217e617..c1edefa5e 100644
--- a/docs/source/incident-reports/2018-03-31-server-start-fail.md
+++ b/docs/source/incident-reports/2018-03-31-server-start-fail.md
@@ -14,14 +14,13 @@ All times in PST
 
 Problem is identified
 
-* Launch success rate drops quickly
-* Many pods stuck in "Terminating" and "ContainerCreating" state.
-* Hub pod is showing many timeout errors.
-
+- Launch success rate drops quickly
+- Many pods stuck in "Terminating" and "ContainerCreating" state.
+- Hub pod is showing many timeout errors.
 
 ### 16:11
 
-* Mount errors on build pods:
+- Mount errors on build pods:
 
 ```
 Events:
@@ -34,18 +33,16 @@ Events:
   Warning  FailedSync             55s (x24 over 5m)  kubelet, gke-prod-a-ssd-pool-32-134a959a-p2kz  Error syncing pod
 ```
 
-
 ### 17:21
 
-* Decided to increase cluster size to 4, wait for new nodes to come up, then cordon the two older nodes
-
+- Decided to increase cluster size to 4, wait for new nodes to come up, then cordon the two older nodes
 
 ### 17:30
 
-* New nodes are up, old nodes are drained
-* Hub / binder pods show up on new nodes
-* Launch success rate begins increasing
-* Launch rate goes back to 100%
+- New nodes are up, old nodes are drained
+- Hub / binder pods show up on new nodes
+- Launch success rate begins increasing
+- Launch rate goes back to 100%
 
 ## Lessons learnt
 
@@ -65,8 +62,8 @@ The outage seemed to come from the deletion of a node, but it seemed to be relat
 
 ### What went wrong
 
-* There was a major outage that we were unable to debug, there were not clear errors in the logs
-* There was only one person available to debug, which made it more difficult to know how to proceed withot any feedback
+- There was a major outage that we were unable to debug, there were not clear errors in the logs
+- There was only one person available to debug, which made it more difficult to know how to proceed withot any feedback
 
 ### Process improvements
 
diff --git a/docs/source/incident-reports/2018-04-18-cull-flood.md b/docs/source/incident-reports/2018-04-18-cull-flood.md
index 732a38671..500c16740 100644
--- a/docs/source/incident-reports/2018-04-18-cull-flood.md
+++ b/docs/source/incident-reports/2018-04-18-cull-flood.md
@@ -19,7 +19,6 @@ Upgrade of jupyterhub, binderhub charts is deployed. Tests pass and builds and l
 
 Launch success drops to zero.
 
-
 ### 14:29
 
 Binder outage is reported on Gitter by @jakamkon, investigation is started.
@@ -122,7 +121,6 @@ and everything is now up-to-date.
 It is observed that the memory leak does not recur,
 confirming that the kubespawner update is the root cause.
 
-
 ## Lessons learned
 
 - It takes about an hour to deploy a change to zero-to-jupyterhub all the way to
@@ -144,15 +142,14 @@ confirming that the kubespawner update is the root cause.
   Reverting a large deploy can result in significant downtime
   during the revert.
 - Three separate bugs were introduced and resolved in this process:
-    1. flood bug in updated culler
-    2. memory leak bug in updated kubespawner
-    3. failure-to-start bug in new image-cleaner
-  More granular continuous deployments would have allowed us to find and catch
-  each of these issues one at a time.
-  On the other hand, deploying at dedicated, less frequent times
-  would allow the team to be prepared to handle and respond to the update process,
-  rather than reacting to issues as they are deployed throughout the week.
-
+  1. flood bug in updated culler
+  2. memory leak bug in updated kubespawner
+  3. failure-to-start bug in new image-cleaner
+     More granular continuous deployments would have allowed us to find and catch
+     each of these issues one at a time.
+     On the other hand, deploying at dedicated, less frequent times
+     would allow the team to be prepared to handle and respond to the update process,
+     rather than reacting to issues as they are deployed throughout the week.
 
 ## Action items
 
diff --git a/docs/source/incident-reports/2018-07-08-podsnips-aplenty.md b/docs/source/incident-reports/2018-07-08-podsnips-aplenty.md
index 37ff8ac8b..e6915d7d0 100644
--- a/docs/source/incident-reports/2018-07-08-podsnips-aplenty.md
+++ b/docs/source/incident-reports/2018-07-08-podsnips-aplenty.md
@@ -7,7 +7,6 @@ resulting in constant growth of pods,
 eventually filling the cluster and new launches failing.
 Total service disruption for Binder lasted for approximately five hours on a Saturday evening.
 
-
 ## Timeline
 
 All times in CEST (UTC+2)
@@ -58,7 +57,7 @@ Shortly thereafter, pod deletion is skipped for pods that launch but are not in
 [W 2018-07-07 16:38:35.506 JupyterHub spawner:1476] No pod jupyter-ipython-2dipython-2din-2ddepth-... to delete. Assuming already deleted.
 ```
 
-These pods *have* started, but aren't registered in the pod reflector,
+These pods _have_ started, but aren't registered in the pod reflector,
 so in aborting the launch, the pod is not deleted.
 This is the direct cause of the runaway pod growth,
 though the root cause is that the pod reflector has stopped updating.
diff --git a/docs/source/incident-reports/2018-07-30-jupyterlab-build-cpu-saturate.md b/docs/source/incident-reports/2018-07-30-jupyterlab-build-cpu-saturate.md
index ba3577c2d..12e3690a5 100644
--- a/docs/source/incident-reports/2018-07-30-jupyterlab-build-cpu-saturate.md
+++ b/docs/source/incident-reports/2018-07-30-jupyterlab-build-cpu-saturate.md
@@ -27,19 +27,19 @@ suggesting that pods aren't being created.
 
 ### 11:22
 
-* Notice an SSL protocol error:
+- Notice an SSL protocol error:
 
   ```
   tornado.curl_httpclient.CurlError: HTTP 599: Unknown SSL protocol error in connection to gcr.io:443
   ```
 
-* Binder pod is deleted and launches return to normal.
+- Binder pod is deleted and launches return to normal.
 
 ### 12:19
 
-* Launches aren't working again, taking a very long time to start up
-* Deleted binder and hub pods
-* This resolved the issue a second time.
+- Launches aren't working again, taking a very long time to start up
+- Deleted binder and hub pods
+- This resolved the issue a second time.
 
 This is the utilization behavior seen:
 
diff --git a/docs/source/incident-reports/2019-02-20-no-logs.md b/docs/source/incident-reports/2019-02-20-no-logs.md
index 112395bd2..12a0a0afb 100644
--- a/docs/source/incident-reports/2019-02-20-no-logs.md
+++ b/docs/source/incident-reports/2019-02-20-no-logs.md
@@ -2,7 +2,6 @@
 
 ## Summary
 
-
 For new builds users did not see the build logs. Builds did happen normally though. Fixed by removing node that had no IP address in its metadata.
 
 ## Timeline
@@ -41,12 +40,11 @@ and `kubectl logs` still fails with:
 Error from server: Get https://10.128.0.17:10250/...?follow=true: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-df315ed616f010764e03"?
 ```
 
-At this point, we know that upgrading master and the nodes will *not* fix `kubectl logs`,
+At this point, we know that upgrading master and the nodes will _not_ fix `kubectl logs`,
 at least for new nodes.
-We do not yet know whether removing old nodes will fix the issue (*spoiler: it will*).
+We do not yet know whether removing old nodes will fix the issue (_spoiler: it will_).
 Investigation begins in earnest.
 
-
 [Troubleshooting documentation](https://cloud.google.com/kubernetes-engine/docs/troubleshooting)
 suggests that something could have gone wrong with the master's ssh access to the nodes.
 
@@ -96,7 +94,6 @@ The node has been cordoned and will be removed from the pool when it is empty.
 with rd5d drained and removed from the pool,
 `kubectl logs` is restored and everything is working.
 
-
 ## Lessons learnt
 
 ### What went well
@@ -131,26 +128,18 @@ Action items. For example,
   The problematic node reported unusually having no known ExternalIP or InternalIP. A normal entry looks like:
 
   ```json
-  [
-    "10.128.xxx.yyy",
-    "35.202.xxx.yyy",
-    "gke-prod-a-user-be5bcf07-xhxd"
-  ]
+  ["10.128.xxx.yyy", "35.202.xxx.yyy", "gke-prod-a-user-be5bcf07-xhxd"]
   ```
 
   while the unhealthy node reported
 
   ```json
-  [
-    "",
-    "gke-prod-a-users-b921bb88-rd5d"
-  ]
+  ["", "gke-prod-a-users-b921bb88-rd5d"]
   ```
 
   indicating that kubernetes had lost track of the node's ExternalIP and InternalIP.
   This was likely a direct symptom of the problem and could be used as a diagnostic in the future.
 
-
 ## Action items
 
 ### Process improvements
diff --git a/docs/source/incident-reports/2020-07-09-simultaneous-launches-scipy.md b/docs/source/incident-reports/2020-07-09-simultaneous-launches-scipy.md
index 5ed286f04..c83a7f70a 100644
--- a/docs/source/incident-reports/2020-07-09-simultaneous-launches-scipy.md
+++ b/docs/source/incident-reports/2020-07-09-simultaneous-launches-scipy.md
@@ -42,10 +42,11 @@ Same chart with annotations for scale-up events:
 
 > Min notes that: this is placeholder pods doing exactly what they are supposed to
 > (ref: [placeholder writeup](https://discourse.jupyter.org/t/planning-placeholders-with-jupyterhub-helm-chart-0-8-tested-on-mybinder-org/213)):
+>
 > 1. pending placeholders is what causes node scale-up before 'real' users need the new node
 > 2. as the new node is ready to accept pods, placeholders start there and go back to running
 > 3. if 100% of placeholders are pending for a period of time waiting for the new node
->    (as they are here), this indicates *user* pods are also waiting for the new node,
+>    (as they are here), this indicates _user_ pods are also waiting for the new node,
 >    which is what placeholder pods are meant to reduce. We should expect a rise in
 >    launch time when this happens. This indicates we do not have enough placeholder
 >    pods.
@@ -81,7 +82,7 @@ even though a new node did not appear to be needed.
 5. According to our metrics, launch success rate never dropped below 100%, but users
    experienced failures. This is perhaps because our timeout is 10 minutes (long!) and a
    first-try failure at 10 minutes followed by a success 5 minutes later is likely experienced as a failure by the user. The
-   launch success rate chart shows 100% success rate *after retry* but high retry rate,
+   launch success rate chart shows 100% success rate _after retry_ but high retry rate,
    indicating timeouts due to load:
 
    ![launch success rate chart](https://i.imgur.com/UiAgdwA.png)
@@ -89,12 +90,11 @@ even though a new node did not appear to be needed.
 6. Users reported experiencing connection errors, but these are not reflected in our
    metrics as failures.
 
-
 ## Action items
 
 ### Process improvements
 
-1. Something about how to notice whether we're hitting GKE node limits? *We
+1. Something about how to notice whether we're hitting GKE node limits? \*We
    can add a threshold to certain Grafana charts, indicating the current limit. Not sure
    how to keep it up-to-date. [issue here](https://github.com/jupyterhub/mybinder.org-deploy/issues/1533).
 2. Consider dedicated nodes or cluster for large events we know are going to use Binder a lot
@@ -125,20 +125,20 @@ issue.
 
    ![launch-time-chart](https://i.imgur.com/dO1FIfw.png)
 
-   If we limit to only the 99th percentile of successful launches, we see that launches *almost never* take longer than 5 minutes and then succeed:
+   If we limit to only the 99th percentile of successful launches, we see that launches _almost never_ take longer than 5 minutes and then succeed:
 
    ![](https://i.imgur.com/rYh0Whv.png)
 
-   If we decrease the launch timeout to 5 minutes, this will likely increase our failure rate, *according to metrics*, but should clear out the queue of what are likely already failed launches *according to users*. The result should be a better experience. [issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/1528).
+   If we decrease the launch timeout to 5 minutes, this will likely increase our failure rate, _according to metrics_, but should clear out the queue of what are likely already failed launches _according to users_. The result should be a better experience. [issue](https://github.com/jupyterhub/mybinder.org-deploy/issues/1528).
 
 3. We should investigate resource allocations to builds, and possible limit concurrent
    builds per repo to a very small number (killing old builds is probably a better user
    experience than blocking new ones), as the failure corresponds to a spike in builds
-   but *not* a spike in launches. [issue for information gathering here](https://github.com/jupyterhub/mybinder.org-deploy/issues/1529).
+   but _not_ a spike in launches. [issue for information gathering here](https://github.com/jupyterhub/mybinder.org-deploy/issues/1529).
 4. Use in-progress metrics (`binderhub_inprogress_launches|builds`) for instant feedback about current launch/build requests.
    Our `launch_time_seconds` metrics are only recorded when the launch either succeeds or
    fails, resulting in an inaccurately smooth and delayed metrics report. For example:
    120 requests in 1 second that complete one at a time over a minute will look like a
-   smooth 2 requests/second in the current metrics. *done in grafana*.
+   smooth 2 requests/second in the current metrics. _done in grafana_.
 5. Implement a quota on prod so that pending pods beyond capacity fail informatively,
    rather than queuing, continuing to add to the load?
diff --git a/docs/source/incident-reports/2022-01-27-prime-version.md b/docs/source/incident-reports/2022-01-27-prime-version.md
index e80edcd5c..7bb2da3ee 100644
--- a/docs/source/incident-reports/2022-01-27-prime-version.md
+++ b/docs/source/incident-reports/2022-01-27-prime-version.md
@@ -72,8 +72,6 @@ resource.type="k8s_pod" resource.labels.cluster_name="prod"
 resource.labels.pod_name=~"^binder.*"
 ```
 
-
-
 ### 2022-01-28 10:00
 
 Underlying issue in federation-redirect is identified and [fixed][fix-pr].
@@ -85,7 +83,6 @@ Underlying issue in federation-redirect is identified and [fixed][fix-pr].
 1. Cluster healed itself when traffic dropped below the prime cluster's pod quota.
 2. federation-redirect logs clearly showed it was the version mismatch preventing traffic.
 
-
 ### What went wrong
 
 1. federation-redirect did not have the correct 'prime version' for 9 hours, due to load on the prime cluster ([fixed][fix-pr])
@@ -102,7 +99,6 @@ Underlying issue in federation-redirect is identified and [fixed][fix-pr].
 
 [status]: https://mybinder.readthedocs.io/en/latest/about/status.html
 
-
 ### Where we got lucky
 
 1. Federation 'as a whole' handled the traffic okay,
@@ -117,14 +113,12 @@ Underlying issue in federation-redirect is identified and [fixed][fix-pr].
 
 1. Implement proactive alerts. This is a longstanding issue we have yet to address ([issue][alerting-issue]).
 
-
 ### Technical improvements
 
 1. Fix bug preventing prime cluster's version from being updated while it is full ([pull request][fix-pr])
 2. Add metrics for the federation-redirect service to improve visibility of federation health issues ([issue][metrics-issue])
 3. Consider allowing the prime cluster to stop accepting traffic when it is unhealthy ([issue][full-issue])
 
-
 [alerting-issue]: https://github.com/jupyterhub/mybinder.org-deploy/issues/611
 [metrics-issue]: https://github.com/jupyterhub/mybinder.org-deploy/issues/2114
 [fix-pr]: https://github.com/jupyterhub/mybinder.org-deploy/pull/2113
diff --git a/docs/source/operation_guide/command_snippets.md b/docs/source/operation_guide/command_snippets.md
index 82721302a..bc6356e34 100644
--- a/docs/source/operation_guide/command_snippets.md
+++ b/docs/source/operation_guide/command_snippets.md
@@ -137,6 +137,7 @@ new_user_pool=user-$(date +"%Y%m%d")
 ```
 
 > Note: You can see a list of the node pools by running:
+
 ```bash
 gcloud container node-pools list --cluster prod --project=binderhub-288415 --zone=us-central1
 ```
@@ -245,10 +246,10 @@ age. You can use it with the following pattern:
 python scripts/delete-pods.py --pod-name <your-query> --older-than <your-query>
 ```
 
-* `--pod-name` is a string and will be matched to any pod that contains this string.
-* `--older-than` is a float (in hours) and will match any pod that is older than this amount.
+- `--pod-name` is a string and will be matched to any pod that contains this string.
+- `--older-than` is a float (in hours) and will match any pod that is older than this amount.
 
-Note, they are both optional, but you need to supply *at least* one. Running
+Note, they are both optional, but you need to supply _at least_ one. Running
 the above command by itself will list all pods that match the query.
 
 ### Delete all pods that match a given name or age
@@ -277,12 +278,12 @@ kubectl --namespace=prod delete pod <POD-NAME> --grace-period=0 --force
 Below is a list of each production pod, and the expected outcome that comes with
 deleting each one.
 
-* `hub-` active user sessions will not be affected. New and pending launches will fail until the new Hub comes back.
-* `binder-` the `mybinder.org` website will temporarily go down. Active user sessions will not be affected.
-* `proxy-` all current users will lose connections (kernel connection lost) until the proxy returns and the Hub restores the routes. Server state is unaffected. Most browser sessions should recover by restoring connections. All pending launches will fail due to lost connections.
-* `proxy-patches-` brief, minor degradation of error messages when browsers attempt to connect to a not-running server. This results in increased load on the Hub, handling requests from browsers whose idle servers have been culled.
-* `redirector-` redirect sites (beta.mybinder.org) will 404 instead of sending to mybinder.org.
-* `jupyter-` deleting a user pod will shut down their session. The user will
+- `hub-` active user sessions will not be affected. New and pending launches will fail until the new Hub comes back.
+- `binder-` the `mybinder.org` website will temporarily go down. Active user sessions will not be affected.
+- `proxy-` all current users will lose connections (kernel connection lost) until the proxy returns and the Hub restores the routes. Server state is unaffected. Most browser sessions should recover by restoring connections. All pending launches will fail due to lost connections.
+- `proxy-patches-` brief, minor degradation of error messages when browsers attempt to connect to a not-running server. This results in increased load on the Hub, handling requests from browsers whose idle servers have been culled.
+- `redirector-` redirect sites (beta.mybinder.org) will 404 instead of sending to mybinder.org.
+- `jupyter-` deleting a user pod will shut down their session. The user will
   encounter errors when they attempt to submit code to the kernel.
 
 ## Node management and information
@@ -295,14 +296,15 @@ event.
 
 To pre-emptively bump the cluster size beyond current occupancy, follow these steps:
 
-* Increase autoscaler minimum size. (note this will lead to a brief period where
+- Increase autoscaler minimum size. (note this will lead to a brief period where
   the kubernetes API is not available.)
-  * Go to https://console.cloud.google.com/
-  * Click "Kubernetes engine" -> "edit" button
-  * Under "Node Pools" find the "minimum size" field and update it.
 
-* Use the `gcloud` command line tool to explicitly resize the cluster.
-  * `gcloud container clusters resize prod --size <NEW-SIZE>`
+  - Go to https://console.cloud.google.com/
+  - Click "Kubernetes engine" -> "edit" button
+  - Under "Node Pools" find the "minimum size" field and update it.
+
+- Use the `gcloud` command line tool to explicitly resize the cluster.
+  - `gcloud container clusters resize prod --size <NEW-SIZE>`
 
 Manually resizing a cluster with autoscaling on doesn't always work because the autoscaler
 can automatically reduce the cluster size after asking for more nodes that
@@ -319,7 +321,7 @@ To remove a node from the cluster, we follow a two-step process. We first
 **cordon** the node, which prevents new pods from being scheduled on it. We then
 **drain** the node, which removes all remaining pods from the node.
 
-* Step 1. Cordon the node
+- Step 1. Cordon the node
 
   ```bash
   kubectl cordon <NODE-NAME>
@@ -327,17 +329,19 @@ To remove a node from the cluster, we follow a two-step process. We first
 
   "cordoning" explicitly tells kubernetes **not** to start new pods on this node.
   For more information on cordoning, see :ref:`term-cordoning`.
-* Step 2. Wait a few hours for pods to naturally get deleted from the node.
-  We'd rather not forcibly delete pods if possible. However if you *need* to
+
+- Step 2. Wait a few hours for pods to naturally get deleted from the node.
+  We'd rather not forcibly delete pods if possible. However if you _need_ to
   delete all the pods on the node, you can skip to step 3.
-* Step 3. Remove all pods from the node
+- Step 3. Remove all pods from the node
 
   ```bash
   kubectl drain --force --delete-local-data --ignore-daemonsets --grace-period=0  <NODE-NAME>
   ```
 
   After running this, the node should now (forcibly) have 0 pods running on it.
-* Step 4. Confirm the node has no pods on it after a few minutes. You can do this
+
+- Step 4. Confirm the node has no pods on it after a few minutes. You can do this
   with:
 
   ```bash
@@ -349,7 +353,7 @@ To remove a node from the cluster, we follow a two-step process. We first
 Once the node has no pods on it, the autoscaler will automatically remove it.
 
 **A note on the need for scaling down with the autoscaler**.
-The autoscaler has issues scaling nodes *down*, so scaling down needs to be
+The autoscaler has issues scaling nodes _down_, so scaling down needs to be
 manually done. The problems are caused by:
 
 1. The cluster autoscaler will never remove nodes that have user pods running.
@@ -385,33 +389,32 @@ The nature of these problems is often hard to debug, but they tend to be
 fixed by "recycling" the nodes (AKA, creating a new node to take the place
 of the older node). Here's the process for recycling nodes.
 
-* **List the node ages.** The following command will list the current nodes
+- **List the node ages.** The following command will list the current nodes
   and their ages.
 
   `kubectl get node`
 
-* **Check if any nodes are > 4 days old.** These are the nodes that we can
+- **Check if any nodes are > 4 days old.** These are the nodes that we can
   recycle.
-* **Cordon the node you'd like to recycle.**
+- **Cordon the node you'd like to recycle.**
 
   `kubectl cordon <NODE-NAME>`
 
-* **If you need a new node immediately.** E.g., if we think a currently-used
+- **If you need a new node immediately.** E.g., if we think a currently-used
   node is causing problems and we need to move production pods to a new node.
 
   In this case, manually resize the cluster up so that a new node is added,
   then delete the relevant pods from the (cordoned) old node.
 
-* **Wait a few hours.** This gives the pods time to naturally leave the node.
-* **Drain the node.** Run the following command to remove all pods from the node.
+- **Wait a few hours.** This gives the pods time to naturally leave the node.
+- **Drain the node.** Run the following command to remove all pods from the node.
 
-  `kubectl drain --force --delete-local-data --ignore-daemonsets --grace-period=0  <NODE-NAME>`
+  `kubectl drain --force --delete-local-data --ignore-daemonsets --grace-period=0 <NODE-NAME>`
 
-* **If it isn't deleted after several hours, delete the node.** with
+- **If it isn't deleted after several hours, delete the node.** with
 
   `kubectl delete <NODE-NAME>`
 
-
 ## Networking
 
 ### Banning traffic
@@ -423,10 +426,10 @@ between Binder and that source.
 We can blacklist traffic in three ways:
 
 1. ingress ip (bans requests to Binder coming from this ip or ip range)
-2. egress ip (bans outgoing traffic *from* Binder to these ip addresses)
+2. egress ip (bans outgoing traffic _from_ Binder to these ip addresses)
 3. egress DNS (disables DNS resolution for specified domains)
 
-All of these are *stored* in the `secrets/ban.py` file.
+All of these are _stored_ in the `secrets/ban.py` file.
 These are not upgraded
 
 To update what should be banned, edit the `secrets/ban.py` file
@@ -445,14 +448,13 @@ If it is an update to the DNS block list, run the `secrets/ban.py` script:
 ./secrets/ban.py gke_binder-prod_us-central1-a_prod-a
 ```
 
-
 ## Acronyms that Chris likes to use in Gitter
 
 It has been pointed out that Chris often employs the use of unusually
 long acronyms. This is a short list of translations so that the world can
 understand his unique and special mind.
 
-* TYVM: Thank You Very Much
-* SGTM: Sounds Good To Me
-* LMKWYT: Let Me Know What You Think
-* WDYT: What Do You Think
+- TYVM: Thank You Very Much
+- SGTM: Sounds Good To Me
+- LMKWYT: Let Me Know What You Think
+- WDYT: What Do You Think
diff --git a/docs/source/operation_guide/common_problems.md b/docs/source/operation_guide/common_problems.md
index 09ceddb1b..d1702a664 100644
--- a/docs/source/operation_guide/common_problems.md
+++ b/docs/source/operation_guide/common_problems.md
@@ -23,23 +23,23 @@ Build pods will not be working, and the `dind` pods are stuck in `CrashLoopBacko
 
 ### How to resolve the problem
 
-1. Find out which node contains the crashing `dind` pod (aka, the node that has
-   *folder* in `/var/run/dind/docker.sock` rather than the socket file).
-   You can do so by running:
+1.  Find out which node contains the crashing `dind` pod (aka, the node that has
+    _folder_ in `/var/run/dind/docker.sock` rather than the socket file).
+    You can do so by running:
 
-       kubectl --namespace=<ns> get pod -o wide
+        kubectl --namespace=<ns> get pod -o wide
 
-2. Once you find the node of interest, SSH into it with:
+2.  Once you find the node of interest, SSH into it with:
 
-       gcloud compute ssh <nodename>
+    gcloud compute ssh <nodename>
 
-3. Manually delete the `docker.sock` folder from the node.
+3.  Manually delete the `docker.sock` folder from the node.
 
-       sudo rm -rf /var/run/dind/docker.sock/
+    sudo rm -rf /var/run/dind/docker.sock/
 
-4. Delete the `dind` pod (k8s will automatically create a new one)
+4.  Delete the `dind` pod (k8s will automatically create a new one)
 
-       kubectl --namespace=<ns> delete pod <dind-pod-name>
+    kubectl --namespace=<ns> delete pod <dind-pod-name>
 
 ## Networking Errors
 
@@ -54,22 +54,22 @@ you want to confirm for yourself that there is no connectivity problem between
 pods follow this recipe.
 
 1. connect to the pod you want to use as "source", for example the jupyterhub
-pod: `kubectl --namespace=prod exec -it hub-989cc9bd-bbkbk /bin/bash`
+   pod: `kubectl --namespace=prod exec -it hub-989cc9bd-bbkbk /bin/bash`
 1. start `python3`, `import requests`
 1. use `requests.get(host)` to check connectivity. Some interesting hostnames
    to try talking to are:
-    * http://binder/, the binderhub service
-    * http://hub:8081/hub/api, the jupyterhub API
-    * http://proxy-public/hub/api, the CHP route that redirects you to the
-      jupyterhub API (content of the response should be equal)
-    * http://google.com/, the internet
-    * the CHP API needs a token so run: `headers={'Authorization': 'token ' + os.environ['CONFIGPROXY_AUTH_TOKEN']}`
-      and then`requests.get('http://proxy-api:8001/api/routes', headers=headers)`
-    * Other hostnames within the Kubernetes deployment. To find out hostnames
-      to try look at the `metadata.name` field of a kubernetes
-      service in the helm chart. You should be able to connect to each of them using
-      the name as the hostname. Take care to use the right port, not all of them are
-      listening on 80.
+   - http://binder/, the binderhub service
+   - http://hub:8081/hub/api, the jupyterhub API
+   - http://proxy-public/hub/api, the CHP route that redirects you to the
+     jupyterhub API (content of the response should be equal)
+   - http://google.com/, the internet
+   - the CHP API needs a token so run: `headers={'Authorization': 'token ' + os.environ['CONFIGPROXY_AUTH_TOKEN']}`
+     and then`requests.get('http://proxy-api:8001/api/routes', headers=headers)`
+   - Other hostnames within the Kubernetes deployment. To find out hostnames
+     to try look at the `metadata.name` field of a kubernetes
+     service in the helm chart. You should be able to connect to each of them using
+     the name as the hostname. Take care to use the right port, not all of them are
+     listening on 80.
 
 Here's a code snippet to try all of the above in quick succession:
 
diff --git a/docs/source/operation_guide/grafana_plots.md b/docs/source/operation_guide/grafana_plots.md
index f37df1a69..e6a2110c3 100644
--- a/docs/source/operation_guide/grafana_plots.md
+++ b/docs/source/operation_guide/grafana_plots.md
@@ -3,15 +3,15 @@
 Below are some links to various plots from grafana, an explanation of what they show and why they are useful to check.
 
 > Many of the plots on grafana have a drop-down menu called "cluster" with three options referring to the different clusters mybinder.org operates on:
-> 
-> * "prometheus" refers to the GKE cluster (US)
-> * "OVH prometheus" refers to the OVH cluster (EU)
-> * "default" is the sum across the clusters
+>
+> - "prometheus" refers to the GKE cluster (US)
+> - "OVH prometheus" refers to the OVH cluster (EU)
+> - "default" is the sum across the clusters
 
-* [Launch/Build Success Rate](https://grafana.mybinder.org/d/3SpLQinmk/1-overview?refresh=1m&orgId=1&var-cluster=default&panelId=16&fullscreen) - This chart is the main indicator that mybinder.org is healthy. If there is a problem, a dropping success rate indicates that it's impacting users. The caveat is that it's an indicator of _current_ status: if builds or launches are failing due to timeouts that it can take a long time to show up as the failure is only reported once it's completed failing. Including retries, this can take several minutes. The [Launch Success Rate](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=9&fullscreen&orgId=1&var-cluster=prometheus) graph shows similar statistics but also includes the number of launch attempts. This can tell us if no-one tried to launch a repo, or if a lot of people tried but failed. Ocassionally, large spikes in launch attempts happen which can be interesting to investigate.
+- [Launch/Build Success Rate](https://grafana.mybinder.org/d/3SpLQinmk/1-overview?refresh=1m&orgId=1&var-cluster=default&panelId=16&fullscreen) - This chart is the main indicator that mybinder.org is healthy. If there is a problem, a dropping success rate indicates that it's impacting users. The caveat is that it's an indicator of _current_ status: if builds or launches are failing due to timeouts that it can take a long time to show up as the failure is only reported once it's completed failing. Including retries, this can take several minutes. The [Launch Success Rate](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=9&fullscreen&orgId=1&var-cluster=prometheus) graph shows similar statistics but also includes the number of launch attempts. This can tell us if no-one tried to launch a repo, or if a lot of people tried but failed. Ocassionally, large spikes in launch attempts happen which can be interesting to investigate.
 
-* [Number of Pods per Node](https://grafana.mybinder.org/d/nDQPwi7mk/node-activity?orgId=1&var-cluster=prometheus&panelId=26&fullscreen&refresh=1m) - This graph shows which nodes are serving the mybinder.org users. This can indicate when auto-scaling may need a helping hand, for example, if one node has had a low load for a long time, it may need to be manually cordoned and drained because a pod is stuck on it.
+- [Number of Pods per Node](https://grafana.mybinder.org/d/nDQPwi7mk/node-activity?orgId=1&var-cluster=prometheus&panelId=26&fullscreen&refresh=1m) - This graph shows which nodes are serving the mybinder.org users. This can indicate when auto-scaling may need a helping hand, for example, if one node has had a low load for a long time, it may need to be manually cordoned and drained because a pod is stuck on it.
 
-* [Number of User Pods over time](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=3&fullscreen&orgId=1&var-cluster=default) - This graph shows how many user pods have been running on mybinder.org. If this seems to be larger than usual, it could be indicative of something interesting, such as posting a blog post or a link on HackerNews that generates a lot of traffic.
+- [Number of User Pods over time](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=3&fullscreen&orgId=1&var-cluster=default) - This graph shows how many user pods have been running on mybinder.org. If this seems to be larger than usual, it could be indicative of something interesting, such as posting a blog post or a link on HackerNews that generates a lot of traffic.
 
-* [Popular repositories](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=1&fullscreen&orgId=1&var-cluster=prometheus) - This graph shows the most popular repos by number of launches in the last hour and, for example, we can see classes that use mybinder.org.
+- [Popular repositories](https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&panelId=1&fullscreen&orgId=1&var-cluster=prometheus) - This graph shows the most popular repos by number of launches in the last hour and, for example, we can see classes that use mybinder.org.
diff --git a/images/analytics-publisher/archiver.py b/images/analytics-publisher/archiver.py
index d7212df3a..f5e93a473 100644
--- a/images/analytics-publisher/archiver.py
+++ b/images/analytics-publisher/archiver.py
@@ -16,41 +16,46 @@ def process_event(event):
 
     Takes in a dict representing event, returns dict back.
     """
-    if 'timestamp' in event:
+    if "timestamp" in event:
         # Trim timestamp to minute resolution before making public
         # Should hopefully make it harder to de-anonymize users by observing timing
-        event['timestamp'] = parse(event['timestamp']).replace(
-            second=0, microsecond=0
-        ).isoformat()
+        event["timestamp"] = (
+            parse(event["timestamp"]).replace(second=0, microsecond=0).isoformat()
+        )
     return event
 
 
 def archive_events(
-    project, log_name, source_bucket, destination_bucket,
-    date, object_name_template='events-{date}.jsonl', debug=False, dry_run=False
+    project,
+    log_name,
+    source_bucket,
+    destination_bucket,
+    date,
+    object_name_template="events-{date}.jsonl",
+    debug=False,
+    dry_run=False,
 ):
     storage_client = storage.Client()
     src_bucket = storage.Bucket(storage_client, source_bucket)
     dest_bucket = storage.Bucket(storage_client, destination_bucket)
 
-
-    prefix = log_name + '/' + date.strftime('%Y/%m/%d')
-    print(f'Finding blobs with prefix {prefix}')
+    prefix = log_name + "/" + date.strftime("%Y/%m/%d")
+    print(f"Finding blobs with prefix {prefix}")
     src_blobs = src_bucket.list_blobs(prefix=prefix)
 
     count = 0
     all_events = []
     for src_blob in src_blobs:
-        with tempfile.TemporaryFile(mode='wb+') as temp:
+        with tempfile.TemporaryFile(mode="wb+") as temp:
             src_blob.download_to_file(temp)
             temp.seek(0)
 
             for line in temp:
-                event = json.loads(json.loads(line)['jsonPayload']['message'])
+                event = json.loads(json.loads(line)["jsonPayload"]["message"])
                 # Account for time when 'event' was nested
-                if 'event' in event:
-                    event.update(event['event'])
-                    del event['event']
+                if "event" in event:
+                    event.update(event["event"])
+                    del event["event"]
                 event = process_event(event)
                 if debug:
                     print(event)
@@ -60,76 +65,75 @@ def archive_events(
 
     if not dry_run:
         # Timestamp is ISO8601 in UTC, so can be sorted lexicographically
-        all_events.sort(key=lambda event: event['timestamp'])
-        with tempfile.TemporaryFile(mode='w+') as out:
+        all_events.sort(key=lambda event: event["timestamp"])
+        with tempfile.TemporaryFile(mode="w+") as out:
             for event in all_events:
-                out.write(json.dumps(event) + '\n')
+                out.write(json.dumps(event) + "\n")
             out.seek(0)
-            blob_name = object_name_template.format(date=date.strftime('%Y-%m-%d'))
+            blob_name = object_name_template.format(date=date.strftime("%Y-%m-%d"))
             blob = dest_bucket.blob(blob_name)
             # Set metadata on the object so we know when this archive is for & how many events there are
             blob.metadata = {
-                'Events-Date': date.strftime('%Y-%m-%d'),
-                'Events-Count': len(all_events)
+                "Events-Date": date.strftime("%Y-%m-%d"),
+                "Events-Count": len(all_events),
             }
             blob.upload_from_file(out)
-            print(f'Uploaded {destination_bucket}/{blob_name} with {count} events')
+            print(f"Uploaded {destination_bucket}/{blob_name} with {count} events")
+
 
 def main():
     argparser = argparse.ArgumentParser()
-    argparser.add_argument(
-        'project',
-        help='Name of the GCP project to read logs from'
-    )
-    argparser.add_argument(
-        'log_name',
-        help='Name of log to read from'
-    )
+    argparser.add_argument("project", help="Name of the GCP project to read logs from")
+    argparser.add_argument("log_name", help="Name of log to read from")
 
     argparser.add_argument(
-        'source_bucket',
-        help='GCS bucket to read exported stackdriver events from'
+        "source_bucket", help="GCS bucket to read exported stackdriver events from"
     )
 
     argparser.add_argument(
-        'destination_bucket',
-        help='GCS bucket to write archived events to'
+        "destination_bucket", help="GCS bucket to write archived events to"
     )
 
     argparser.add_argument(
-        '--date',
-        help='Date to archive events for. Defaults to today',
+        "--date",
+        help="Date to archive events for. Defaults to today",
         type=parse,
-        default=datetime.utcnow().isoformat()
+        default=datetime.utcnow().isoformat(),
     )
 
     argparser.add_argument(
-        '--object-name-template',
-        help='Template to use when outputting archived events. {date} is substituted',
-        default='events-{date}.jsonl'
+        "--object-name-template",
+        help="Template to use when outputting archived events. {date} is substituted",
+        default="events-{date}.jsonl",
     )
 
     argparser.add_argument(
-        '--debug',
-        help='Print events when processing',
-        action='store_true',
-        default=False
+        "--debug",
+        help="Print events when processing",
+        action="store_true",
+        default=False,
     )
 
     argparser.add_argument(
-        '--dry-run',
-        help='Do not upload processed events to GCS',
-        action='store_true',
-        default=False
+        "--dry-run",
+        help="Do not upload processed events to GCS",
+        action="store_true",
+        default=False,
     )
 
     args = argparser.parse_args()
 
     archive_events(
-        args.project, args.log_name, args.source_bucket, args.destination_bucket,
-        args.date, args.object_name_template, args.debug, args.dry_run
+        args.project,
+        args.log_name,
+        args.source_bucket,
+        args.destination_bucket,
+        args.date,
+        args.object_name_template,
+        args.debug,
+        args.dry_run,
     )
 
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     main()
diff --git a/images/analytics-publisher/cloudcosts.py b/images/analytics-publisher/cloudcosts.py
index c4895bcc9..1d9fd9a46 100644
--- a/images/analytics-publisher/cloudcosts.py
+++ b/images/analytics-publisher/cloudcosts.py
@@ -13,8 +13,8 @@ def totals_from_csv(file):
     totals = {}
     reader = csv.DictReader(file)
     for row in reader:
-        time_range = (row['Start Time'], row['End Time'])
-        totals[time_range] = totals.get(time_range, 0) + float(row['Cost'])
+        time_range = (row["Start Time"], row["End Time"])
+        totals[time_range] = totals.get(time_range, 0) + float(row["Cost"])
 
     return totals
 
@@ -22,30 +22,35 @@ def totals_from_csv(file):
 def totals_from_json(file):
     totals = {}
     for item in json.load(file):
-        cost = float(item['cost']['amount'])
-        time_range = (item['start_time'], item['end_time'])
+        cost = float(item["cost"]["amount"])
+        time_range = (item["start_time"], item["end_time"])
         totals[time_range] = totals.get(time_range, 0) + cost
 
     return totals
 
+
 def publish_daily_cost(
-        billing_bucket_name, target_bucket_name, target_object_name,
-        kind='json', debug=False, dry_run=False
-    ):
+    billing_bucket_name,
+    target_bucket_name,
+    target_object_name,
+    kind="json",
+    debug=False,
+    dry_run=False,
+):
     totals = {}
     client = storage.Client()
 
     bucket = storage.Bucket(client, billing_bucket_name)
-    if kind == 'csv':
-        prefix='report-'
+    if kind == "csv":
+        prefix = "report-"
     else:
-        prefix='billing-'
+        prefix = "billing-"
     blobs = bucket.list_blobs(prefix=prefix)
 
     for blob in blobs:
         buffer = io.StringIO(blob.download_as_string().decode())
 
-        if kind == 'csv':
+        if kind == "csv":
             current_totals = totals_from_csv(buffer)
         else:
             current_totals = totals_from_json(buffer)
@@ -53,19 +58,13 @@ def publish_daily_cost(
         for time_range, cost in current_totals.items():
             totals[time_range] = totals.get(time_range, 0) + cost
 
-
     # We want to push out sorted jsonl
     sorted_items = [
-        {
-            'version': 1,
-            'start_time': start_time,
-            'end_time': end_time,
-            'cost': cost
-        }
+        {"version": 1, "start_time": start_time, "end_time": end_time, "cost": cost}
         for (start_time, end_time), cost in totals.items()
     ]
 
-    sorted_items.sort(key=lambda d: d['start_time'])
+    sorted_items.sort(key=lambda d: d["start_time"])
 
     if debug:
         for item in sorted_items:
@@ -77,7 +76,7 @@ def publish_daily_cost(
 
         target_buffer = io.StringIO()
         for item in sorted_items:
-            target_buffer.write(json.dumps(item) + '\n')
+            target_buffer.write(json.dumps(item) + "\n")
 
         target_buffer.seek(0)
 
@@ -85,45 +84,48 @@ def publish_daily_cost(
 
     return sorted_items
 
+
 def main():
     argparser = argparse.ArgumentParser()
     argparser.add_argument(
-        'billing_bucket_name',
-        help='Name of bucket GCP billing data is exported to'
+        "billing_bucket_name", help="Name of bucket GCP billing data is exported to"
     )
     argparser.add_argument(
-        'target_bucket_name',
-        help='Name of bucket to push aggregate daily data to'
+        "target_bucket_name", help="Name of bucket to push aggregate daily data to"
     )
     argparser.add_argument(
-        'target_object_name',
-        help='Name of object to output containing aggregate daily data'
+        "target_object_name",
+        help="Name of object to output containing aggregate daily data",
     )
     argparser.add_argument(
-        '--kind',
-        choices=('csv', 'json'),
-        help='Content Type of billing data export available in bucket',
-        default='json'
+        "--kind",
+        choices=("csv", "json"),
+        help="Content Type of billing data export available in bucket",
+        default="json",
     )
     argparser.add_argument(
-        '--debug',
-        help='Print daily billing data to stdout',
-        action='store_true',
-        default=False
+        "--debug",
+        help="Print daily billing data to stdout",
+        action="store_true",
+        default=False,
     )
     argparser.add_argument(
-        '--dry-run',
-        help='Do not push output to output GCS bucket',
-        action='store_true',
-        default=False
+        "--dry-run",
+        help="Do not push output to output GCS bucket",
+        action="store_true",
+        default=False,
     )
 
     args = argparser.parse_args()
     publish_daily_cost(
-        args.billing_bucket_name, args.target_bucket_name, args.target_object_name,
-        args.kind, args.debug, args.dry_run
+        args.billing_bucket_name,
+        args.target_bucket_name,
+        args.target_object_name,
+        args.kind,
+        args.debug,
+        args.dry_run,
     )
 
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     main()
diff --git a/images/analytics-publisher/indexer.py b/images/analytics-publisher/indexer.py
index 61a9c4df2..e1976f0a2 100644
--- a/images/analytics-publisher/indexer.py
+++ b/images/analytics-publisher/indexer.py
@@ -20,33 +20,38 @@
 HERE = os.path.dirname(os.path.abspath(__file__))
 
 # Static files that should be uploaded by indexer
-STATIC_FILES = glob(os.path.join(HERE, 'static', 'bootstrap-4.1.3.min.css'))
+STATIC_FILES = glob(os.path.join(HERE, "static", "bootstrap-4.1.3.min.css"))
 
 
 def index_events(project, bucket, debug=False, dry_run=False):
     storage_client = storage.Client()
     bucket = storage.Bucket(storage_client, bucket)
 
-    blobs = bucket.list_blobs(prefix='events-')
+    blobs = bucket.list_blobs(prefix="events-")
 
     archives = []
 
-    with open(os.path.join(HERE, 'index.html')) as f:
+    with open(os.path.join(HERE, "index.html")) as f:
         html_template = jinja2.Template(f.read())
 
     for blob in blobs:
-        archives.append({
-            'name': blob.name,
-            'date': blob.metadata['Events-Date'],
-            'count': blob.metadata['Events-Count']
-        })
+        archives.append(
+            {
+                "name": blob.name,
+                "date": blob.metadata["Events-Date"],
+                "count": blob.metadata["Events-Count"],
+            }
+        )
 
-    with tempfile.TemporaryFile(mode='w+') as htmlfile, \
-         tempfile.TemporaryFile(mode='w+') as jsonlfile:
+    with tempfile.TemporaryFile(mode="w+") as htmlfile, tempfile.TemporaryFile(
+        mode="w+"
+    ) as jsonlfile:
 
         html_index = html_template.render(
-            archives=sorted(archives, key=lambda archive: archive['date'], reverse=True),
-            generated_time=datetime.utcnow().isoformat() + 'Z'
+            archives=sorted(
+                archives, key=lambda archive: archive["date"], reverse=True
+            ),
+            generated_time=datetime.utcnow().isoformat() + "Z",
         )
 
         if debug:
@@ -55,18 +60,17 @@ def index_events(project, bucket, debug=False, dry_run=False):
         htmlfile.write(html_index)
 
         for archive in archives:
-            jsonlfile.write(json.dumps(archive) + '\n')
+            jsonlfile.write(json.dumps(archive) + "\n")
 
         htmlfile.seek(0)
         jsonlfile.seek(0)
 
         if not dry_run:
-            html_blob = bucket.blob('index.html')
-            html_blob.upload_from_file(htmlfile, content_type='text/html')
-            print('Uploaded index.html')
-            bucket.blob('index.jsonl').upload_from_file(jsonlfile)
-            print('Uploaded index.jsonl')
-
+            html_blob = bucket.blob("index.html")
+            html_blob.upload_from_file(htmlfile, content_type="text/html")
+            print("Uploaded index.html")
+            bucket.blob("index.jsonl").upload_from_file(jsonlfile)
+            print("Uploaded index.jsonl")
 
     # Upload static assets
     for static_file in STATIC_FILES:
@@ -74,33 +78,29 @@ def index_events(project, bucket, debug=False, dry_run=False):
         static_blob = bucket.blob(blob_name)
         mimetype, _ = mimetypes.guess_type(static_file)
         static_blob.upload_from_filename(static_file, content_type=mimetype)
-        print(f'Uploaded static file {blob_name}')
+        print(f"Uploaded static file {blob_name}")
 
 
 def main():
     argparser = argparse.ArgumentParser()
-    argparser.add_argument(
-        'project',
-        help='Name of the GCP project to read logs from'
-    )
+    argparser.add_argument("project", help="Name of the GCP project to read logs from")
 
     argparser.add_argument(
-        'bucket',
-        help='GCS bucket to read archived event files from'
+        "bucket", help="GCS bucket to read archived event files from"
     )
 
     argparser.add_argument(
-        '--debug',
-        help='Print events when processing',
-        action='store_true',
-        default=False
+        "--debug",
+        help="Print events when processing",
+        action="store_true",
+        default=False,
     )
 
     argparser.add_argument(
-        '--dry-run',
-        help='Do not upload processed events to GCS',
-        action='store_true',
-        default=False
+        "--dry-run",
+        help="Do not upload processed events to GCS",
+        action="store_true",
+        default=False,
     )
 
     args = argparser.parse_args()
@@ -108,5 +108,5 @@ def main():
     index_events(args.project, args.bucket, args.debug, args.dry_run)
 
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     main()
diff --git a/images/analytics-publisher/run.py b/images/analytics-publisher/run.py
index 1336a3304..d94556725 100755
--- a/images/analytics-publisher/run.py
+++ b/images/analytics-publisher/run.py
@@ -7,10 +7,10 @@
 from cloudcosts import publish_daily_cost
 from indexer import index_events
 
-with open('/etc/analytics-publisher/analytics-publisher.json') as f:
+with open("/etc/analytics-publisher/analytics-publisher.json") as f:
     config = json.load(f)
 
-project_name = config['project']
+project_name = config["project"]
 
 while True:
     now = datetime.utcnow()
@@ -21,38 +21,38 @@
         # Running last day's for first 5h makes sure we catch last day's events, even if an
         # archiving run is disrupted for any reason
         yesterday = now - timedelta(days=1)
-        print("Archiving yesterday's events {}".format(yesterday.strftime('%Y-%m-%d')))
+        print("Archiving yesterday's events {}".format(yesterday.strftime("%Y-%m-%d")))
         archive_events(
             project=project_name,
-            log_name=config['events']['logName'],
-            source_bucket=config['events']['sourceBucket'],
-            destination_bucket=config['destinationBucket'],
-            date=yesterday
+            log_name=config["events"]["logName"],
+            source_bucket=config["events"]["sourceBucket"],
+            destination_bucket=config["destinationBucket"],
+            date=yesterday,
         )
 
-    print("Archiving today's events {}".format(now.strftime('%Y-%m-%d')))
+    print("Archiving today's events {}".format(now.strftime("%Y-%m-%d")))
     archive_events(
         project=project_name,
-        log_name=config['events']['logName'],
-        source_bucket=config['events']['sourceBucket'],
-        destination_bucket=config['destinationBucket'],
-        date=now
+        log_name=config["events"]["logName"],
+        source_bucket=config["events"]["sourceBucket"],
+        destination_bucket=config["destinationBucket"],
+        date=now,
     )
 
-    if config['cloudCosts']['enabled']:
+    if config["cloudCosts"]["enabled"]:
         # Only publish cloudCosts if it is enabled.
         # We disable this for binder staging, since all our billing
         # exports are in prod only.
         cloud_costs = publish_daily_cost(
-            billing_bucket_name=config['cloudCosts']['sourceBucket'],
-            target_bucket_name=config['destinationBucket'],
-            target_object_name=config['cloudCosts']['fileName'],
-            kind=config['cloudCosts']['kind']
+            billing_bucket_name=config["cloudCosts"]["sourceBucket"],
+            target_bucket_name=config["destinationBucket"],
+            target_object_name=config["cloudCosts"]["fileName"],
+            kind=config["cloudCosts"]["kind"],
         )
 
         print(f"Uploaded cloud costs for {len(cloud_costs)} days")
 
     print("Generating index")
-    index_events(project_name, config['destinationBucket'])
-    print('Sleeping for 2h')
+    index_events(project_name, config["destinationBucket"])
+    print("Sleeping for 2h")
     time.sleep(2 * 60 * 60)
diff --git a/images/federation-redirect/app.py b/images/federation-redirect/app.py
index 1caaa9c50..539d54eed 100644
--- a/images/federation-redirect/app.py
+++ b/images/federation-redirect/app.py
@@ -158,8 +158,7 @@ def cache_key(uri):
 
 REDIRECTS = Gauge(
     "federation_redirect_count",
-    "Number of requests routed to each member."
-    " 'member' is the federation member.",
+    "Number of requests routed to each member." " 'member' is the federation member.",
     ["member"],
 )
 
@@ -239,8 +238,12 @@ def prepare(self):
         hosts = dict(self.settings["hosts"])  # make a copy
         if not hosts:
             # no healthy hosts, allow routing to unhealthy 'prime' host only
-            hosts = {key: host for key, host in CONFIG["hosts"].items() if host.get("prime")}
-            app_log.warning(f"Using unhealthy prime host(s) {list(hosts)} because zero hosts are healthy")
+            hosts = {
+                key: host for key, host in CONFIG["hosts"].items() if host.get("prime")
+            }
+            app_log.warning(
+                f"Using unhealthy prime host(s) {list(hosts)} because zero hosts are healthy"
+            )
         self.hosts = hosts
         self.hosts_by_url = {}  # dict of {"https://gke.mybinder.org": "gke"}
         self.host_names = []  # ordered list of ["gke"]
@@ -318,7 +321,9 @@ async def health_check(host, active_hosts):
                 if all_hosts[host].get("prime", False):
                     old_versions = CONFIG.get("versions", None)
                     if old_versions != versions:
-                        app_log.info(f"Updating prime versions {old_versions}->{versions}")
+                        app_log.info(
+                            f"Updating prime versions {old_versions}->{versions}"
+                        )
                         CONFIG["versions"] = versions
                 # check if this cluster is on the same versions as the prime
                 # w/o information about the prime's version we allow each
diff --git a/images/federation-redirect/test_rendezvous.py b/images/federation-redirect/test_rendezvous.py
index d285ad182..9989b71bb 100644
--- a/images/federation-redirect/test_rendezvous.py
+++ b/images/federation-redirect/test_rendezvous.py
@@ -28,6 +28,6 @@ def test_100_0_split():
     # check that a bucket with zero weight never gets selected
     # the weight of bucket "a" doesn't matter
     result = Counter(
-        [rendezvous_rank([("a", 0.8), ("b", 0.)], "key-%i" % i)[0] for i in range(100)]
+        [rendezvous_rank([("a", 0.8), ("b", 0.0)], "key-%i" % i)[0] for i in range(100)]
     )
     assert Counter({"a": 100}) == result
diff --git a/images/tc-init/README.md b/images/tc-init/README.md
index 555baa8e1..28cf08ebb 100644
--- a/images/tc-init/README.md
+++ b/images/tc-init/README.md
@@ -9,13 +9,13 @@ Currently, only egress bandwidth limits work (sending data out of the container)
 ...if you don't have to!
 
 Kubernetes has [annotations](https://github.com/kubernetes/kubernetes/blob/v1.8.4/pkg/util/bandwidth/utils.go#L38)
-that *should* enable you to accomplish bandwidth limits without any help:
+that _should_ enable you to accomplish bandwidth limits without any help:
 
 ```yaml
 spec:
   annotations:
-  - kubernetes.io/egress-bandwidth: 1M
-  - kubernetes.io/ingress-bandwidth: 10M
+    - kubernetes.io/egress-bandwidth: 1M
+    - kubernetes.io/ingress-bandwidth: 10M
 ```
 
 Unfortunately, I've found that many network implementations do not respect these annotations (as of kubernetes 1.8, anyway),
@@ -34,13 +34,13 @@ For example:
 ```yaml
 spec:
   initContainers:
-  - name: tc-init
-    image: jupyterhub/mybinder.org-tc-init
-    env:
-    - name: EGRESS_BANDWIDTH
-      value: 1mbit
-    securityContext:
-      capabilities:
-        add:
-        - NET_ADMIN
+    - name: tc-init
+      image: jupyterhub/mybinder.org-tc-init
+      env:
+        - name: EGRESS_BANDWIDTH
+          value: 1mbit
+      securityContext:
+        capabilities:
+          add:
+            - NET_ADMIN
 ```
diff --git a/images/tc-init/example.yml b/images/tc-init/example.yml
index 4124d2220..f10988eef 100644
--- a/images/tc-init/example.yml
+++ b/images/tc-init/example.yml
@@ -5,18 +5,18 @@ metadata:
   name: test-pod
 spec:
   initContainers:
-  - name: tc-init
-    image: jupyterhub/mybinder.org-tc-init:set-by-chartpress
-    env:
-    - name: EGRESS_BANDWIDTH
-      value: 1mbit
-    # ingress doesn't seem to work
-    # - name: INGRESS_BANDWIDTH
-    #   value: 4mbit
-    securityContext:
-      capabilities:
-        add:
-        - NET_ADMIN
+    - name: tc-init
+      image: jupyterhub/mybinder.org-tc-init:set-by-chartpress
+      env:
+        - name: EGRESS_BANDWIDTH
+          value: 1mbit
+      # ingress doesn't seem to work
+      # - name: INGRESS_BANDWIDTH
+      #   value: 4mbit
+      securityContext:
+        capabilities:
+          add:
+            - NET_ADMIN
   containers:
-  - name: main
-    image: jupyter/minimal-notebook:e89b2fe9974b
+    - name: main
+      image: jupyter/minimal-notebook:e89b2fe9974b
diff --git a/mybinder/files/etc/jupyter/jupyter_notebook_config.py b/mybinder/files/etc/jupyter/jupyter_notebook_config.py
index 657f0cbe4..b69d6744d 100644
--- a/mybinder/files/etc/jupyter/jupyter_notebook_config.py
+++ b/mybinder/files/etc/jupyter/jupyter_notebook_config.py
@@ -3,28 +3,30 @@
 
 import notebook
 
-c.NotebookApp.extra_template_paths.append('/etc/jupyter/templates')
+c.NotebookApp.extra_template_paths.append("/etc/jupyter/templates")
 
 
 # For old notebook versions we have to explicitly enable the translation
 # extension
-if V(notebook.__version__) < V('5.1.0'):
-    c.NotebookApp.jinja_environment_options = {'extensions': ['jinja2.ext.i18n']}
+if V(notebook.__version__) < V("5.1.0"):
+    c.NotebookApp.jinja_environment_options = {"extensions": ["jinja2.ext.i18n"]}
 
 
-binder_launch_host = os.environ.get('BINDER_LAUNCH_HOST', '')
-binder_request = os.environ.get('BINDER_REQUEST', '')
-binder_persistent_request = os.environ.get('BINDER_PERSISTENT_REQUEST', '')
+binder_launch_host = os.environ.get("BINDER_LAUNCH_HOST", "")
+binder_request = os.environ.get("BINDER_REQUEST", "")
+binder_persistent_request = os.environ.get("BINDER_PERSISTENT_REQUEST", "")
 
-repo_url = os.environ.get('BINDER_REPO_URL', '')
+repo_url = os.environ.get("BINDER_REPO_URL", "")
 
 # Disable JITSI integration for now
-jitsi_url = ''
-
-c.NotebookApp.jinja_template_vars.update({
-    'binder_url': binder_launch_host+binder_request,
-    'persistent_binder_url': binder_launch_host+binder_persistent_request,
-    'repo_url': repo_url,
-    'ref_url': os.environ.get('BINDER_REF_URL', ''),
-    'jitsi_url': jitsi_url,
-})
+jitsi_url = ""
+
+c.NotebookApp.jinja_template_vars.update(
+    {
+        "binder_url": binder_launch_host + binder_request,
+        "persistent_binder_url": binder_launch_host + binder_persistent_request,
+        "repo_url": repo_url,
+        "ref_url": os.environ.get("BINDER_REF_URL", ""),
+        "jitsi_url": jitsi_url,
+    }
+)
diff --git a/mybinder/values.yaml b/mybinder/values.yaml
index 76cd05048..17f21842b 100644
--- a/mybinder/values.yaml
+++ b/mybinder/values.yaml
@@ -18,7 +18,7 @@ tags: {}
 etcJupyter:
   jupyter_notebook_config.json:
     NotebookApp:
-      allow_origin: '*'
+      allow_origin: "*"
       tornado_settings:
         trust_xheaders: true
       # shutdown the server after no activity
@@ -39,7 +39,6 @@ etcJupyter:
       cull_connected: true
 
 binderhub:
-
   replicas: 2
 
   resources:
@@ -90,7 +89,8 @@ binderhub:
         # ferarussia is clearly a fake GitHub account created by GuitarsAI to get around ban
         # it was created the day GuitarsAI was blocked and does the same thing
         - ^ferarussia/.*
-      high_quota_specs: []
+      high_quota_specs:
+        []
         # - ^jupyterlab/.*
         # - ^jupyter/.*
         # - ^jupyterhub/.*
@@ -112,7 +112,6 @@ binderhub:
       #   config:
       #     quota: 123
 
-
     GitRepoProvider:
       banned_specs:
         - ^(git|https?)%3A%2F%2Fgithub.com%2Fa2nk%2F.*
@@ -286,8 +285,8 @@ binderhub:
             "/": "http://proxy-patches"
       service:
         annotations:
-          prometheus.io/scrape: 'true'
-          prometheus.io/path: '/hub/metrics'
+          prometheus.io/scrape: "true"
+          prometheus.io/path: "/hub/metrics"
     proxy:
       service:
         type: ClusterIP
@@ -315,7 +314,7 @@ binderhub:
       annotations:
         ingress.kubernetes.io/proxy-body-size: 64m
         kubernetes.io/ingress.class: nginx
-        kubernetes.io/tls-acme: 'true'
+        kubernetes.io/tls-acme: "true"
     scheduling:
       userScheduler:
         enabled: true
@@ -385,9 +384,9 @@ binderhub:
             - name: EGRESS_BANDWIDTH
               value: 1mbit
           securityContext:
-          # capabilities.add seems to be disabled
-          # by the `runAsUser: 1000` in the pod-level securityContext
-          # unless we explicitly run as root
+            # capabilities.add seems to be disabled
+            # by the `runAsUser: 1000` in the pod-level securityContext
+            # unless we explicitly run as root
             runAsUser: 0
             capabilities:
               add:
@@ -443,8 +442,8 @@ ingress-nginx:
       enabled: true
       service:
         annotations:
-          prometheus.io/scrape: 'true'
-          prometheus.io/port: '10254'
+          prometheus.io/scrape: "true"
+          prometheus.io/port: "10254"
     service:
       # Preserve client IPs
       externalTrafficPolicy: Local
@@ -455,7 +454,7 @@ redirector:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'true'
+      kubernetes.io/tls-acme: "true"
     tls:
       secretName: kubelego-tls-redirector
 
@@ -466,7 +465,7 @@ static:
   ingress:
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'true'
+      kubernetes.io/tls-acme: "true"
     tls:
       secretName: kubelego-tls-static
 
@@ -476,7 +475,7 @@ grafana:
     enabled: true
     annotations:
       kubernetes.io/ingress.class: nginx
-      kubernetes.io/tls-acme: 'true'
+      kubernetes.io/tls-acme: "true"
   # deploymentStrategy.type is set to Recreate as we have storage that can only
   # be attached once, we can't have two replicas as RollingUpdate leads to.
   deploymentStrategy:
@@ -523,7 +522,7 @@ prometheus:
       enabled: true
       annotations:
         kubernetes.io/ingress.class: nginx
-        kubernetes.io/tls-acme: 'true'
+        kubernetes.io/tls-acme: "true"
 
 proxyPatches:
   enabled: true
@@ -552,7 +551,7 @@ analyticsPublisher:
     logName: binderhub-events-text
   image:
     name: jupyterhub/mybinder.org-analytics-publisher
-    tag: 'set-by-chartpress'
+    tag: "set-by-chartpress"
   cloudCosts:
     # All billing info goes into same bucket in prod, to which staging has access
     enabled: true
@@ -570,7 +569,7 @@ federationRedirect:
   enabled: false
   image:
     name: jupyterhub/mybinder.org-federation-redirect
-    tag: 'set-by-chartpress'
+    tag: "set-by-chartpress"
   check:
     period: 15
     jitter: 0.1
diff --git a/post-grafana-annotation.py b/post-grafana-annotation.py
index a1dfb5b33..2f80e6ddc 100644
--- a/post-grafana-annotation.py
+++ b/post-grafana-annotation.py
@@ -26,44 +26,36 @@ def create_annotation(grafana_url, grafana_api_key, tags, text):
     return requests.post(
         grafana_url + "/api/annotations",
         json={
-            'tags': tags,
-            'text': text,
-            'time': int(time.time() * 1000),
-            'isRegion': False
+            "tags": tags,
+            "text": text,
+            "time": int(time.time() * 1000),
+            "isRegion": False,
         },
-        headers={
-            'Authorization': f'Bearer {grafana_api_key}'
-        }
+        headers={"Authorization": f"Bearer {grafana_api_key}"},
     ).text
 
 
 def main():
     argparser = argparse.ArgumentParser()
-    argparser.add_argument(
-        '--grafana-url',
-        help='URL of the grafana instance to use'
-    )
+    argparser.add_argument("--grafana-url", help="URL of the grafana instance to use")
 
     argparser.add_argument(
-        '--tag',
-        help='Tags to add to the annotation',
+        "--tag",
+        help="Tags to add to the annotation",
         default=[],
-        action='append',
-        dest='tags'
+        action="append",
+        dest="tags",
     )
 
-    argparser.add_argument(
-        'text',
-        help='Text to use for the annotation'
-    )
+    argparser.add_argument("text", help="Text to use for the annotation")
 
     args = argparser.parse_args()
-    print(create_annotation(
-        args.grafana_url,
-        os.environ['GRAFANA_API_KEY'],
-        args.tags, 
-        args.text
-    ))
+    print(
+        create_annotation(
+            args.grafana_url, os.environ["GRAFANA_API_KEY"], args.tags, args.text
+        )
+    )
+
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     main()
diff --git a/scripts/datacenters.py b/scripts/datacenters.py
index 9c31e7cf5..36cd96e99 100755
--- a/scripts/datacenters.py
+++ b/scripts/datacenters.py
@@ -22,7 +22,7 @@ def cidrs_aws():
     url = "https://ip-ranges.amazonaws.com/ip-ranges.json"
     r = requests.get(url)
     r.raise_for_status()
- 
+
     return [prefix["ip_prefix"] for prefix in r.json()["prefixes"]]
 
 
@@ -42,6 +42,7 @@ def cidrs_gcp():
 
 class MicrosoftDownloadParser(HTMLParser):
     """Minimal HTML parser to find microsoft download links"""
+
     def __init__(self):
         super().__init__()
         self.links = []
diff --git a/scripts/delete-pods.py b/scripts/delete-pods.py
index 1d63790ad..cfac973f7 100644
--- a/scripts/delete-pods.py
+++ b/scripts/delete-pods.py
@@ -22,17 +22,36 @@
 
 # Setup our parameters
 argparser = argparse.ArgumentParser()
-argparser.add_argument("--older-than", type=float, default=0, help="Pods older than this many hours will be killed (can be fractions of an hour)")
-argparser.add_argument("--delete", action="store_true", help="Confirm deleting the pods rather than just printing info")
-argparser.add_argument("--namespace", default="prod", help="Namespace to perform actions in")
-argparser.add_argument("--pod-name", default="", help="Only delete pods with `pod-name` in the pod name.")
-
-kube_context_help = ("Context pointing to the cluster to use. To list the "
-                     "current activated context, run `kubectl config get-contexts`")
-argparser.add_argument("--kube-context", default="gke_binder-prod_us-central1-a_prod-a", help=kube_context_help)
+argparser.add_argument(
+    "--older-than",
+    type=float,
+    default=0,
+    help="Pods older than this many hours will be killed (can be fractions of an hour)",
+)
+argparser.add_argument(
+    "--delete",
+    action="store_true",
+    help="Confirm deleting the pods rather than just printing info",
+)
+argparser.add_argument(
+    "--namespace", default="prod", help="Namespace to perform actions in"
+)
+argparser.add_argument(
+    "--pod-name", default="", help="Only delete pods with `pod-name` in the pod name."
+)
+
+kube_context_help = (
+    "Context pointing to the cluster to use. To list the "
+    "current activated context, run `kubectl config get-contexts`"
+)
+argparser.add_argument(
+    "--kube-context",
+    default="gke_binder-prod_us-central1-a_prod-a",
+    help=kube_context_help,
+)
 args = argparser.parse_args()
 
-if args.older_than == 0 and args.pod_name == '':
+if args.older_than == 0 and args.pod_name == "":
     raise ValueError("Must specify at least one of `pod-name` or `pod-age`.")
 
 # Load and operate on current kubernetes config
@@ -41,23 +60,33 @@
 # Get list of pods with given label selector in the 'prod' namespace
 core_api = client.CoreV1Api()
 
-pods = core_api.list_namespaced_pod(args.namespace, label_selector="component=singleuser-server")
+pods = core_api.list_namespaced_pod(
+    args.namespace, label_selector="component=singleuser-server"
+)
 total_pods = []
 for pod in pods.items:
     # API results always use UTC timezone
-    age = datetime.now(timezone.utc) - pod.status.start_time.replace(tzinfo=timezone.utc)
+    age = datetime.now(timezone.utc) - pod.status.start_time.replace(
+        tzinfo=timezone.utc
+    )
     if age > timedelta(hours=args.older_than):
         # If pod-name isn't specified, this will always be true
         if args.pod_name not in pod.metadata.name:
             continue
         if args.delete:
-            core_api.delete_namespaced_pod(pod.metadata.name, args.namespace, client.V1DeleteOptions())
-            print(f"Deleted {age.total_seconds() / 60 / 60:.1f}h old pod {pod.metadata.name}")
-            summary_text = 'Deleted {} pods'
+            core_api.delete_namespaced_pod(
+                pod.metadata.name, args.namespace, client.V1DeleteOptions()
+            )
+            print(
+                f"Deleted {age.total_seconds() / 60 / 60:.1f}h old pod {pod.metadata.name}"
+            )
+            summary_text = "Deleted {} pods"
         else:
-            print(f"Found {age.total_seconds() / 60 / 60:.1f}h old pod {pod.metadata.name}")
-            summary_text = 'Found {} pods'
+            print(
+                f"Found {age.total_seconds() / 60 / 60:.1f}h old pod {pod.metadata.name}"
+            )
+            summary_text = "Found {} pods"
 
         total_pods.append(pod.metadata.name)
-        
-print('---', '\n', summary_text.format(len(total_pods)))
+
+print("---", "\n", summary_text.format(len(total_pods)))
diff --git a/scripts/drain-user-node b/scripts/drain-user-node
index 73b066132..4f813df60 100755
--- a/scripts/drain-user-node
+++ b/scripts/drain-user-node
@@ -138,10 +138,7 @@ for node in nodes_to_drain:
     delete_count = len(to_delete)
     print(f"{dry_prefix}The following {delete_count} pods will be deleted:")
     print(
-        "  "
-        + "\n  ".join(
-            f"{pod.metadata.name} {reason}" for pod, reason in to_delete
-        )
+        "  " + "\n  ".join(f"{pod.metadata.name} {reason}" for pod, reason in to_delete)
     )
     if not args.answer_yes and not args.dry_run:
         ans = input(f"Delete {delete_count} pods [y/N? ")
diff --git a/scripts/list_new_commits.py b/scripts/list_new_commits.py
index 19978c7ce..41214a0d0 100644
--- a/scripts/list_new_commits.py
+++ b/scripts/list_new_commits.py
@@ -1,47 +1,63 @@
 import requests
 from yaml import safe_load as load
 
-print('Fetching the SHA for live BinderHub and repo2docker...')
+print("Fetching the SHA for live BinderHub and repo2docker...")
 
 # Load master requirements
 url_requirements = "https://raw.githubusercontent.com/jupyterhub/mybinder.org-deploy/master/mybinder/Chart.yaml"
 requirements = load(requests.get(url_requirements).text)
-binderhub_dep = [ii for ii in requirements['dependencies'] if ii['name'] == 'binderhub'][0]
-bhub_live = binderhub_dep['version'].split('-')[-1]
+binderhub_dep = [
+    ii for ii in requirements["dependencies"] if ii["name"] == "binderhub"
+][0]
+bhub_live = binderhub_dep["version"].split("-")[-1]
 
 url_binderhub_requirements = f"https://raw.githubusercontent.com/jupyterhub/binderhub/{bhub_live}/helm-chart/binderhub/requirements.yaml"
 requirements = load(requests.get(url_binderhub_requirements).text)
-jupyterhub_dep = [ii for ii in requirements['dependencies'] if ii['name'] == 'jupyterhub'][0]
-jhub_live = jupyterhub_dep['version'].split('-')[-1]
+jupyterhub_dep = [
+    ii for ii in requirements["dependencies"] if ii["name"] == "jupyterhub"
+][0]
+jhub_live = jupyterhub_dep["version"].split("-")[-1]
 
 # Load master repo2docker
 url_helm_chart = "https://raw.githubusercontent.com/jupyterhub/mybinder.org-deploy/master/mybinder/values.yaml"
 helm_chart = requests.get(url_helm_chart)
 helm_chart = load(helm_chart.text)
-r2d_live = helm_chart['binderhub']['config']['BinderHub']['build_image'].split(':')[-1]
+r2d_live = helm_chart["binderhub"]["config"]["BinderHub"]["build_image"].split(":")[-1]
 
-print('Fetching latest commit SHA for BinderHub and repo2docker...')
+print("Fetching latest commit SHA for BinderHub and repo2docker...")
 
 # Load latest r2d commit from dockerhub
 url = "https://hub.docker.com/v2/repositories/jupyter/repo2docker/tags/"
 resp = requests.get(url)
-r2d_master = resp.json()['results'][0]['name']
+r2d_master = resp.json()["results"][0]["name"]
 
 # Load latest binderhub and jupyterhub commits
-url_helm_chart = 'https://raw.githubusercontent.com/jupyterhub/helm-chart/gh-pages/index.yaml'
+url_helm_chart = (
+    "https://raw.githubusercontent.com/jupyterhub/helm-chart/gh-pages/index.yaml"
+)
 helm_chart_yaml = load(requests.get(url_helm_chart).text)
 
 latest_hash = {}
-for repo in ['binderhub', 'jupyterhub']:
-    updates_sorted = sorted(helm_chart_yaml['entries'][repo], key=lambda k: k['created'])
-    latest_hash[repo] = updates_sorted[-1]['version'].split('-')[-1]
-
-url_bhub = 'https://github.com/jupyterhub/binderhub/compare/{}...{}'.format(bhub_live, latest_hash['binderhub'])
-url_r2d = f'https://github.com/jupyterhub/repo2docker/compare/{r2d_live}...{r2d_master[:8]}'
-url_jhub = 'https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/{}...{}'.format(jhub_live, latest_hash['jupyterhub'])
-
-print('---------------------\n')
-print(f'BinderHub: {url_bhub}')
-print(f'repo2docker: {url_r2d}')
-print(f'JupyterHub: {url_jhub}')
-print('\n---------------------')
+for repo in ["binderhub", "jupyterhub"]:
+    updates_sorted = sorted(
+        helm_chart_yaml["entries"][repo], key=lambda k: k["created"]
+    )
+    latest_hash[repo] = updates_sorted[-1]["version"].split("-")[-1]
+
+url_bhub = "https://github.com/jupyterhub/binderhub/compare/{}...{}".format(
+    bhub_live, latest_hash["binderhub"]
+)
+url_r2d = (
+    f"https://github.com/jupyterhub/repo2docker/compare/{r2d_live}...{r2d_master[:8]}"
+)
+url_jhub = (
+    "https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/{}...{}".format(
+        jhub_live, latest_hash["jupyterhub"]
+    )
+)
+
+print("---------------------\n")
+print(f"BinderHub: {url_bhub}")
+print(f"repo2docker: {url_r2d}")
+print(f"JupyterHub: {url_jhub}")
+print("\n---------------------")
diff --git a/scripts/load-test.py b/scripts/load-test.py
index 13d1a0ce2..63baac1c3 100644
--- a/scripts/load-test.py
+++ b/scripts/load-test.py
@@ -7,22 +7,20 @@
 import requests
 
 
-def build_binder(repo,
-                 ref='master',
-                 binder_url='https://mybinder.org'):
+def build_binder(repo, ref="master", binder_url="https://mybinder.org"):
     """Launch a binder"""
-    url = binder_url + f'/build/gh/{repo}/{ref}'
+    url = binder_url + f"/build/gh/{repo}/{ref}"
     r = requests.get(url, stream=True)
     r.raise_for_status()
     for line in r.iter_lines():
-        line = line.decode('utf8', 'replace')
-        if line.startswith('data:'):
-            yield json.loads(line.split(':', 1)[1])
+        line = line.decode("utf8", "replace")
+        if line.startswith("data:"):
+            yield json.loads(line.split(":", 1)[1])
 
 
-def launch_binder(n, repo, ref='master', filepath=None,
-                  binder_url='https://mybinder.org',
-                  delay=10):
+def launch_binder(
+    n, repo, ref="master", filepath=None, binder_url="https://mybinder.org", delay=10
+):
     """Launch a new binder from `repo` at `ref`
 
     Use `delay` to delay the launch by a random amount in seconds.
@@ -36,9 +34,9 @@ def launch_binder(n, repo, ref='master', filepath=None,
     total_bytes = 0
 
     for evt in build_binder(repo, ref=ref, binder_url=binder_url):
-        if 'message' in evt:
+        if "message" in evt:
             pass
-        if evt.get('phase') == 'ready':
+        if evt.get("phase") == "ready":
             ready_at = time.time()
             s = requests.Session()
 
@@ -47,7 +45,7 @@ def launch_binder(n, repo, ref='master', filepath=None,
             else:
                 url = "{url}notebooks/{filepath}?token={token}".format(
                     filepath=filepath, **evt
-                    )
+                )
 
             # GET the notebook
             r = s.get(url)
@@ -57,76 +55,77 @@ def launch_binder(n, repo, ref='master', filepath=None,
 
             # spawn a kernel
             url = "{url}api/sessions?token={token}".format(**evt)
-            r = s.post(url, json={"path": "Foobar.ipynb",
-                                  "type": "notebook",
-                                  "name": "",
-                                  "kernel": {"id": None,
-                                             "name": "python3"
-                                             }
-                                  }
-                       )
+            r = s.post(
+                url,
+                json={
+                    "path": "Foobar.ipynb",
+                    "type": "notebook",
+                    "name": "",
+                    "kernel": {"id": None, "name": "python3"},
+                },
+            )
             r.raise_for_status()
             kernel_at = time.time()
             total_bytes += len(r.content)
 
             # biggest file in the session
-            url = ("{url}nbextensions/jupyter-js-widgets/"
-                   "extension.js?v=20180705212711&token={token}".format(**evt)
-                   )
+            url = (
+                "{url}nbextensions/jupyter-js-widgets/"
+                "extension.js?v=20180705212711&token={token}".format(**evt)
+            )
             r = s.get(url)
             r.raise_for_status()
             widgets_at = time.time()
             total_bytes += len(r.content)
 
             done_at = time.time()
-            return {'idx': n,
-                    'start': launched_at,
-                    'ready': ready_at,
-                    'kernel': kernel_at,
-                    'notebook': notebook_at,
-                    'widgets': widgets_at,
-                    'end': done_at,
-                    'total_bytes': total_bytes,
-                    'status': 'success',
-                    }
+            return {
+                "idx": n,
+                "start": launched_at,
+                "ready": ready_at,
+                "kernel": kernel_at,
+                "notebook": notebook_at,
+                "widgets": widgets_at,
+                "end": done_at,
+                "total_bytes": total_bytes,
+                "status": "success",
+            }
 
     else:
         failed_at = time.time()
         print(n, "never launched.")
-        return {'idx': n, 'start': launched_at, 'end': failed_at,
-                'status': 'fail'}
+        return {"idx": n, "start": launched_at, "end": failed_at, "status": "fail"}
 
 
-if __name__ == '__main__':
+if __name__ == "__main__":
     parser = argparse.ArgumentParser(description=__doc__)
-    parser.add_argument('repo', type=str, help="The GitHub repo to build")
-    parser.add_argument(
-        '--ref', default='master', help="The ref of the repo to build")
-    parser.add_argument(
-        '--filepath', default=None, help="The notebook to open")
+    parser.add_argument("repo", type=str, help="The GitHub repo to build")
+    parser.add_argument("--ref", default="master", help="The ref of the repo to build")
+    parser.add_argument("--filepath", default=None, help="The notebook to open")
     parser.add_argument(
-        '--results', default='results.json', help="File name to store results in")
+        "--results", default="results.json", help="File name to store results in"
+    )
     parser.add_argument(
-        '--n-launches', default=5, help='Number of launches to perform',
-        type=int)
+        "--n-launches", default=5, help="Number of launches to perform", type=int
+    )
     parser.add_argument(
-        '--binder',
-        default='https://mybinder.org',
+        "--binder",
+        default="https://mybinder.org",
         help="""
         The URL of the binder instance to use.
         Use `http://localhost:8585` if you are doing local testing.
-    """)
+    """,
+    )
     opts = parser.parse_args()
 
     gun_time = time.time()
     with ThreadPoolExecutor(max_workers=100) as executor:
         results = {}
         for n in range(opts.n_launches):
-            job = executor.submit(launch_binder, n,
-                                  opts.repo, opts.ref, opts.filepath)
+            job = executor.submit(launch_binder, n, opts.repo, opts.ref, opts.filepath)
             results[job] = n
 
-        print('launching...')
+        print("launching...")
         launches = []
         for future in as_completed(results):
             idx = results[future]
@@ -135,21 +134,22 @@ def launch_binder(n, repo, ref='master', filepath=None,
                 # save it for later
                 launches.append(launch)
             except Exception as exc:
-                print('{!r} generated an exception: {}'.format(idx, exc))
+                print(f"{idx!r} generated an exception: {exc}")
             else:
-                if launch['status'] == 'success':
-                    print('Launch %r succeeded and took %is' %
-                          (idx, launch['end'] - launch['start'])
-                          )
+                if launch["status"] == "success":
+                    print(
+                        "Launch %r succeeded and took %is"
+                        % (idx, launch["end"] - launch["start"])
+                    )
                 else:
-                    print('Launch %r failed and took %is' %
-                          (idx, launch['end'] - launch['start'])
-                          )
+                    print(
+                        "Launch %r failed and took %is"
+                        % (idx, launch["end"] - launch["start"])
+                    )
 
-    with open(opts.results, 'w') as f:
-        json.dump({'gun_time': gun_time,
-                   'results': launches},
-                  f)
+    with open(opts.results, "w") as f:
+        json.dump({"gun_time": gun_time, "results": launches}, f)
 
     import pprint
+
     pprint.pprint(launches)
diff --git a/terraform/README.md b/terraform/README.md
index 662398c36..26b4426bd 100644
--- a/terraform/README.md
+++ b/terraform/README.md
@@ -48,7 +48,6 @@ terraform output -json private_keys | jq '.["events-archiver"]' | pbcopy
 
 with key names: "events-archiver", "matomo", and "binderhub-builder" and paste them into the appropriate fields in `secrets/config/$deployment.yaml`.
 
-
 ### Notes
 
 - requesting previously-allocated static ip via loadBalancerIP did not work.
diff --git a/tests/conftest.py b/tests/conftest.py
index 86c9571d8..080dfe8d7 100644
--- a/tests/conftest.py
+++ b/tests/conftest.py
@@ -3,14 +3,10 @@
 
 def pytest_addoption(parser):
     parser.addoption(
-        "--binder-url",
-        help="Fully qualified URL to the binder installation"
+        "--binder-url", help="Fully qualified URL to the binder installation"
     )
 
-    parser.addoption(
-        "--hub-url",
-        help="Fully qualified URL to the hub installation"
-    )
+    parser.addoption("--hub-url", help="Fully qualified URL to the hub installation")
 
 
 @pytest.fixture
diff --git a/tests/test_build.py b/tests/test_build.py
index 10fdd7eec..c9b43cbee 100644
--- a/tests/test_build.py
+++ b/tests/test_build.py
@@ -21,17 +21,19 @@ def push_dummy_gh_branch(repo, branch, keyfile):
     clone directory when done.
     """
 
-    git_env = {'GIT_SSH_COMMAND': f"ssh -i {keyfile}"}
+    git_env = {"GIT_SSH_COMMAND": f"ssh -i {keyfile}"}
 
     with tempfile.TemporaryDirectory() as gitdir:
-        subprocess.check_call(['git', 'clone', repo, gitdir], env=git_env)
-        branchfile = os.path.join(gitdir, 'branchname')
-        with open(branchfile, 'w') as f:
+        subprocess.check_call(["git", "clone", repo, gitdir], env=git_env)
+        branchfile = os.path.join(gitdir, "branchname")
+        with open(branchfile, "w") as f:
             f.write(branch)
-        subprocess.check_call(['git', 'add', branchfile], cwd=gitdir)
-        subprocess.check_call(['git', 'commit', '-m', f'Dummy update for {branch}'], cwd=gitdir)
+        subprocess.check_call(["git", "add", branchfile], cwd=gitdir)
         subprocess.check_call(
-            ['git', 'push', 'origin', f'HEAD:{branch}'],
+            ["git", "commit", "-m", f"Dummy update for {branch}"], cwd=gitdir
+        )
+        subprocess.check_call(
+            ["git", "push", "origin", f"HEAD:{branch}"],
             env=git_env,
             cwd=gitdir,
         )
@@ -41,20 +43,19 @@ def push_dummy_gh_branch(repo, branch, keyfile):
         finally:
             # Delete the branch so we don't clutter!
             subprocess.check_call(
-                ['git', 'push', 'origin', f':{branch}'],
+                ["git", "push", "origin", f":{branch}"],
                 env=git_env,
                 cwd=gitdir,
             )
 
 
-
 @pytest.mark.timeout(498)
 def test_build_binder(binder_url):
     """
     We can launch an image that we know hasn't been built
     """
     branch = str(time.time())
-    repo = 'binderhub-ci-repos/cached-minimal-dockerfile'
+    repo = "binderhub-ci-repos/cached-minimal-dockerfile"
 
     with push_dummy_gh_branch(
         f"git@github.com:/{repo}.git",
@@ -66,26 +67,24 @@ def test_build_binder(binder_url):
         r = requests.get(build_url, stream=True)
         r.raise_for_status()
         for line in r.iter_lines():
-            line = line.decode('utf8')
-            if line.startswith('data:'):
-                data = json.loads(line.split(':', 1)[1])
+            line = line.decode("utf8")
+            if line.startswith("data:"):
+                data = json.loads(line.split(":", 1)[1])
                 # include message output for debugging
-                if data.get('message'):
-                    sys.stdout.write(data['message'])
-                if data.get('phase') == 'ready':
-                    notebook_url = data['url']
-                    token = data['token']
+                if data.get("message"):
+                    sys.stdout.write(data["message"])
+                if data.get("phase") == "ready":
+                    notebook_url = data["url"]
+                    token = data["token"]
                     break
         else:
             # This means we never got a 'Ready'!
             assert False
 
-        headers = {
-            'Authorization': f'token {token}'
-        }
-        r = requests.get(notebook_url + '/api', headers=headers)
+        headers = {"Authorization": f"token {token}"}
+        r = requests.get(notebook_url + "/api", headers=headers)
         assert r.status_code == 200
-        assert 'version' in r.json()
+        assert "version" in r.json()
 
-        r = requests.post(notebook_url + '/api/shutdown', headers=headers)
+        r = requests.post(notebook_url + "/api/shutdown", headers=headers)
         assert r.status_code == 200
diff --git a/tests/test_http.py b/tests/test_http.py
index 54ada4e25..f8f7ba514 100644
--- a/tests/test_http.py
+++ b/tests/test_http.py
@@ -11,7 +11,7 @@ def test_binder_up(binder_url):
     """
     resp = requests.get(binder_url)
     assert resp.status_code == 200
-    assert 'GitHub' in resp.text
+    assert "GitHub" in resp.text
 
 
 def test_hub_health(hub_url):
diff --git a/tests/test_launch.py b/tests/test_launch.py
index bdbdb62b2..e0117ebe6 100644
--- a/tests/test_launch.py
+++ b/tests/test_launch.py
@@ -10,29 +10,27 @@ def test_launch_binder(binder_url):
     We can launch an image that most likely already has been built.
     """
     # Known good version of this repo
-    repo = 'binder-examples/requirements'
-    ref = 'fa84f12'
-    build_url = binder_url + f'/build/gh/{repo}/{ref}'
+    repo = "binder-examples/requirements"
+    ref = "fa84f12"
+    build_url = binder_url + f"/build/gh/{repo}/{ref}"
     r = requests.get(build_url, stream=True)
     r.raise_for_status()
     for line in r.iter_lines():
-        line = line.decode('utf8')
-        if line.startswith('data:'):
-            data = json.loads(line.split(':', 1)[1])
-            if data.get('phase') == 'ready':
-                notebook_url = data['url']
-                token = data['token']
+        line = line.decode("utf8")
+        if line.startswith("data:"):
+            data = json.loads(line.split(":", 1)[1])
+            if data.get("phase") == "ready":
+                notebook_url = data["url"]
+                token = data["token"]
                 break
     else:
         # This means we never got a 'Ready'!
         assert False
 
-    headers = {
-        'Authorization': f'token {token}'
-    }
-    r = requests.get(notebook_url + '/api', headers=headers)
+    headers = {"Authorization": f"token {token}"}
+    r = requests.get(notebook_url + "/api", headers=headers)
     assert r.status_code == 200
-    assert 'version' in r.json()
+    assert "version" in r.json()
 
-    r = requests.post(notebook_url + '/api/shutdown', headers=headers)
+    r = requests.post(notebook_url + "/api/shutdown", headers=headers)
     assert r.status_code == 200