diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index ad847dbb..1384832c 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -5,30 +5,15 @@ PRIORITY - ALWAYS Lowest level stuff first, i.e. TODO at server, api route chang
 WIFI change 5g channel to 44 and 2g channel to 8 
 
 todo: OPS view metrics
-	- view metrics
-	- this could be made to look really cool, take a brief amount of time to see what can be done re graphs etc and make v.next cases if too involved for now
-	https://github.com/AppMetrics/AppMetrics
-	https://www.app-metrics.io/
-	https://www.app-metrics.io/samples/grafana/
-	https://www.chartjs.org/samples/latest/
-	https://www.chartjs.org/docs/latest/#creating-a-chart
-	https://github.com/apertureless/vue-chartjs/
-	https://vue-chartjs.org/guide/
-	https://webdesign.tutsplus.com/tutorials/build-a-dynamic-dashboard-with-chartjs--webdesign-14363
-	https://blog.hubspot.com/marketing/types-of-graphs-for-data-visualization
+	Figure out what metrics to add and add them
+	
+	route metrics, slowest etc bottlenecks!
+
+
 	https://www.datadoghq.com/blog/monitoring-101-collecting-data/
 
-	REconsidering it all, as app.metrics seems to be losing it's way, never really worked properly with asp.net core 3.x so far 
-	is on a 4.0 release and has bugs apparently and it's always been a lot of fuckery to use
-	OPTIONS:
-	Health checks
-		https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-3.1
-			does db and server not sure about performance or errors etc must research
-	Roll my own stats thing
-		The metrics was to collect vast amounts of real time data about routes being hit etc, but it's a fail for that exact purpose 
-		so strip out app.metrics and instead just log to db a months worth of data collected every X minutes or so
-		Some things will need to be logged more frequently than others, for example disk space every minute seems pointless
-		Memory usage as well, maybe on a longer time frame?
+	Memory usage as well, maybe on a longer time frame?
+
 		Then can feed this data to a graph at the client and be useful to see trend over time 
 		REPLICATE DIGITAL OCEAN UI
 			some of the items are irrelevant probably, but the time frame yes
@@ -57,26 +42,13 @@ todo: OPS view metrics
 			BANDWIDTH? (maybe not practical)	
 		Avg response time
 
-		ACTION:
-			Strip out app.metrics entirely, remove all trace 
-			Add my own code to snapshot key values from 
-			Implement as much of this as possible / practical
-				https://www.datadoghq.com/blog/monitoring-101-collecting-data/
-			Add routes to get stats
-			Add UI to view stats like D.O., simple, easy peasy
-			Add ISSUE triage:
-				When stats are gathered checks thresholds and might trigger some form of notification
-				No more than once per 24 hour period , don't want a scenario where a thousand notifications are sent pointlessly
-				Need PAGE / INSTANT OPS notification for emergency shit
-				Regular notification for non emergency but important to look at shit
-				Normal logging for logging level issues
 
 
-VIEWING 1 minute stats:
-
-TEST data
 
 
+todo: add a basic health check route:
+	Health checks
+		https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-3.1
  
 todo: Are UTC filters really working properly?	
 	Check that a datafilter with dates incoming datetime ranges are either interpreted as UTC on route (from post formdata maybe, already know query params are NOT)