diff --git a/docs/dev-of-the-week.md b/docs/dev-of-the-week.md
new file mode 100644
index 0000000000000..871333b3cca28
--- /dev/null
+++ b/docs/dev-of-the-week.md
@@ -0,0 +1,49 @@
+# Dev of the Week Overview
+
+So you want to learn about Dev of the Week! Maybe it's your first time as DotW, or it's been a few months and you want a refresher on everything you need to cover. This document is written as a TODO list, with items look at 2-3x per week or in response to alerts (usually in the Developer HipChat room).
+
+Dev of the Week is on point for any issues that arise in the Production, Test, or Staging environments. You don't have to personally fix every issue, but DotW is responsible for delegating and coordinating fixes. There are the main areas:
+
+* 2-3x per week
+ * [Check New & Existing Zendesk Tickets](#zendesk)
+* As notified in the Developers HipChat room
+ * [Investigate Build Failures](#build-failures)
+ * [Level Activity Monitor](#level-activity-monitor)
+ * [HoneyBadger Notifications](#honeybadger-notifications)
+
+This is a living document. Please update it to help the next DotW, and to help future-you next time you're DotW. You can edit directly in GitHub via the pencil icon at the top right.
+
+### Zendesk
+
+See the [Zendesk doc](https://github.com/code-dot-org/code-dot-org/blob/staging/docs/dev-of-the-week-zendesk.md) for specific steps. Check for new issues and follow up on pending items 2-3x over the course of the week.
+
+### Build Failures
+
+
+
+The fastest way to track these down is to look at the commits that have occurred since the last successful build. If nothing jumps out as the culprit, pull the latest changes and try building them locally to find the breakage.
+
+When in doubt, ask in the Developers HipChat room.
+
+### Level Activity Monitor
+
+
+
+These notifications are generated when a blockly level has received `MinimumAttemptsPerHour` (default: 5 attempts) in the past `HoursToTest` (default: 2 hours) with zero successes. Some levels are known to be more difficult and have higher tolerances in [activity-monitor](https://github.com/code-dot-org/code-dot-org/blob/staging/bin/activity-monitor).
+
+1. When a level shows up in HipChat it's in the format `/level/n` which is the direct link to the level by ID. Open this link in your browser.
+1. If the link is an unplugged level, add it to the excluded list. Done!
+1. Otherwise, _ensure you are logged in as an admin_ then look at the bottom of the left sidebar to edit the level and view public-facing links (under "This level is in the following scripts:").
+1. Use the public-facing link to load the level in the target browser via .
+1. Play through the level to see if it's passable.
+ 1. Passing the level on BrowserStack via the public-facing link will register as a success and stop the HipChat notifications. Consider increasing the tolerance for common false-positives.
+ 1. If the level is unplayable, fix the level by clicking the edit link (for levels created in levelbuilder — must be logged in as an admin) or by editing the corresponding .level file.
+1. Update the [blocky per-level-alert outliers](https://docs.google.com/a/code.org/spreadsheets/d/1Va5hKlT6-uQJ0mZ6_QpDIaeBIhAjem-n1egWn316tJM/) ghseet if the level needs to be redesigned to address difficulty.
+
+An attempt is defined as the user loading the page and a success is the user solving the puzzle so the "Congratulations" dialog appears. See `activity_start` in `ScriptLevelsController::show` and `activity_finish` in `ActivitiesController::milestone`.
+
+### HoneyBadger Notifications
+
+
+
+See the [Using Honeybadger](https://github.com/code-dot-org/code-dot-org/blob/staging/docs/honeybadger.md) doc for workflow.
diff --git a/docs/honeybadger.md b/docs/honeybadger.md
new file mode 100644
index 0000000000000..124126d47f72b
--- /dev/null
+++ b/docs/honeybadger.md
@@ -0,0 +1,39 @@
+# Using Honeybadger
+
+Everything in Honeybadger should be assigned to someone, which is equivalent to "I've looked at it, doesn't need to be fixed right away". Every actual bug should be a pivotal item — Honeybadger things are bugs like any other bug so should be tracked in pivotal (there's not a perfect 1-1 mapping from honeybadger to pivotal because honeybadger is not perfect about determining whether an item is a duplicate).
+
+First steps: (only need to do this once)
+
+- Add your pivotal key in
+- Configure notifications in
+
+Views:
+
+- Default view (all unresolved):
+
+- Unresolved bugs assigned to nobody:
+
+
+When looking at a new honeybadger item:
+
+- If it's a new fault
+ - If it's urgent
+ - Fix it
+ - If it's not urgent
+ - Create a pivotal item (can do this with one click from honeybadger)
+ - Assign the pivotal item to a person
+ - Assign the honeybadger item to the same person
+ - If it's a dupe of another honeybadger item or already tracked in pivotal
+ - Assign the honeybadger item to the person who the dupe is already assigned to
+ - Comment on the honeybadger item if it's not obvious what/why it's a dupe
+- If it's an existing thing that is assigned to you
+ - Look at it and verify that it hasn't changed the priority/urgency of the bug
+- If it's an existing thing that is assigned to someone else
+ - You don't need to do anything, they will take care of it
+- If you are sure the right thing to do is to ignore the bug
+ - Choose Ignore in honeybadger
+ **Note!** most of the time the right thing to do is handle it in the code. you should leave it unresolved and track it if it's something that should be handled in code but is low priority
+
+When you fix something:
+
+- Resolve the honeybadger item when your fix is on production (if there's a pivotal item track it as any other pivotal item). Resolve basically says "I think this is fixed -- notify me if it happens again", so you should resolve it when production is fixed, not e.g. when you are done with the work.