Remove documentation on stoppage alerts.

docs/speed/perf_regression_sheriffing.md

 # Perf Regression Sheriffing (go/perfregression-sheriff)
 
 The perf regression sheriff tracks performance regressions in Chrome's
 continuous integration tests. Note that a [new rotation](perf_bot_sheriffing.md)
 has been created to ensure the builds and tests stay green, so the perf
 regression sheriff role is now entirely focused on performance.
 
 **[Rotation calendar](https://calendar.google.com/calendar/embed?src=google.com_2fpmo740pd1unrui9d7cgpbg2k%40group.calendar.google.com)**
 
 ## Key Responsibilities
 
  * [Triage Regressions on the Perf Dashboard](#Triage-Regressions-on-the-Perf-Dashboard)
- * [Triaging Data Stoppage Alerts](#Triaging-Data-Stoppage-Alerts)
  * [Follow up on Performance Regressions](#Follow-up-on-Performance-Regressions)
  * [Give Feedback on our Infrastructure](#Give-Feedback-on-our-Infrastructure)
 
 ## Triage Regressions on the Perf Dashboard
 
 Open the perf dashboard [alerts page](https://chromeperf.appspot.com/alerts).
 
 In the upper right corner, **sign in with your Chromium account**. Signing in is
 important in order to be able to kick off bisect jobs, and see data from
 internal waterfalls.
 
-Pick up **Chromium Perf Sheriff** from "Select an item ▼" drop down menu. There
-are two tables of alerts that may be shown:
-
- * "Performance Alerts"
- * "Data Stoppage Alerts"
-
-For either type of alert, if there are no currently pending alerts, then the
-table won't be shown.
+Pick up **Chromium Perf Sheriff** from "Select an item ▼" drop down menu.
+table of "Performance Alerts" should be shown. If there are no currently pending
+alerts, then the table won't be shown.
 
 The list can be sorted by clicking on the column header. When you click on the
 checkbox next to an alert, all the other alerts that occurred in the same
 revision range will be highlighted.
 
 Check the boxes next to the alerts you want to take a look at, and click the
 "Graph" button. You'll be taken to a page with a table at the top listing all
 the alerts that have an overlapping revision range with the one you chose, and
 below it the dashboard shows graphs of all the alerts checked in that table.
 
@@ skipping 31 matching lines @@
    tooltip on the graph. If you see any likely culprits, cc the authors on the
    bug.
 6. **Optionally, kick off more bisects**. The perf dashboard will automatically
    kick off a bisect for each bug you file. But if you think the regression is
    much clearer on one platform, or a specific page of a page set, or you want
    to see a broader revision range feel free to click on the alert on that graph
    and kick off a bisect for it. There should be capacity to kick off as many
    bisects as you feel are necessary to investigate; [give feedback](#feedback)
    below if you feel that is not the case.
 
-## Triaging Data Stoppage Alerts
-
-Data stoppage alerts are listed on the
-[perf dashboard alerts page](https://chromeperf.appspot.com/alerts). Whenever
-the dashboard is monitoring a metric, and that metric stops sending data, an
-alert is fired. See
-[triaging data stoppage alerts](triaging_data_stoppage_alerts.md) for more
-details.
-
 ## Follow up on Performance Regressions
 
 During your shift, you should try to follow up on each of the bugs you filed.
 Once you've triaged all the alerts, check to see if the bisects have come back,
 or if they failed. If the results came back, and a culprit was found, follow up
 with the CL author. If the bisects failed to update the bug with results, please
 file a bug on it (see [feedback](#feedback) links below).
 
 Also during your shift, please spend any spare time driving down bugs from the
 [regression backlog](http://go/triage-backlog). Treat these bugs as you would
@@ skipping 32 matching lines @@
   [go/bad-bisects](https://docs.google.com/spreadsheets/d/13PYIlRGE8eZzsrSocA3SR2LEHdzc8n9ORUoOE2vtO6I/edit#gid=0).
   The team triages these regularly. If you spot a really clear bug (bisect
   job red, bugs not being updated with bisect results) please file it in
   crbug with component `Speed>Bisection`. If a bisect problem is blocking a
   perf regression bug triage, **please file a new bug with component
   `Speed>Bisection` and block the regression bug on the bisect bug**. This
   makes it much easier for the team to triage, dupe, and close bugs on the
   infrastructure without affecting the state of the perf regression bugs.
 * **Noisy Tests**: Please file a bug in crbug with component `Speed>Benchmarks`
   and [cc the owner](http://go/perf-owners).