diff --git a/README.md b/README.md
index 67d8211..d1637bf 100644
--- a/README.md
+++ b/README.md
@@ -3,10 +3,10 @@ chroprof - Profiling for [Chronos](https://github.com/status-im/nim-chronos)
 
 This repo contains a usable profiler for [Chronos](https://github.com/status-im/nim-chronos). For the time being, it requires a modified version of Chronos ([V3](https://github.com/codex-storage/nim-chronos/tree/feature/profiler), [V4](https://github.com/codex-storage/nim-chronos/tree/feature/profiler-v4)) which has profiling hooks enabled.
 
-1. [Enabling profiling]()
-2. [Looking at metrics]()
-2. [Enabling profiling with Prometheus metrics]()
-3. [Limitations]()
+1. [Enabling profiling](#enabling-profiling)
+2. [Looking at metrics](#looking-at-metrics)
+2. [Enabling profiling with Prometheus metrics](#enabling-profiling-with-prometheus-metrics)
+3. [Limitations](#limitations)
 
 
 ## Enabling Profiling
@@ -23,9 +23,10 @@ enableProfiling()
 ## Looking at Metrics
 
 At any time during execution, you can get a snapshot of the profiler metrics 
-by calling `getMetrics()`. This will return a [`MetricsTotals`]() object which
-is a table mapping [`FutureType`]()s to [`AggregateMetrics`](). You may then
-print, log, or do whatever you like with those. 
+by calling `getMetrics()`. This will return a [`MetricsTotals`](https://github.com/codex-storage/nim-chroprof/blob/master/chroprof/profiler.nim#L56) object which
+is a table mapping [`FutureType`](https://github.com/codex-storage/nim-chroprof/blob/master/chroprof/profiler.nim#L13)s to 
+[`AggregateMetrics`](https://github.com/codex-storage/nim-chroprof/blob/master/chroprof/profiler.nim#L17). You may then 
+print, log, or do whatever you like with those, including [export them to Prometheus](#enabling-profiling-with-prometheus-metrics).
 
 `getMetrics()` will return the metrics for the event loop that is running 
 (or ran) on the calling thread.
@@ -33,7 +34,7 @@ print, log, or do whatever you like with those.
 ## Enabling profiling with Prometheus metrics
 
 You can export metrics on the top-`k` async procs that are occupying the event
-loop thread the most by enabling the profiler's [nim-metrics]() collector:
+loop thread the most by enabling the profiler's [nim-metrics](https://github.com/status-im/nim-metrics/) collector:
 
 ```nim
 import chroprof/collector
@@ -42,4 +43,18 @@ import chroprof/collector
 enableProfilerMetrics(50)
 ```
 
-with the help of [Grafana](), 
\ No newline at end of file
+with the help of [Grafana](https://grafana.com/), one can visualize and readily identify bottlenecks:
+
+![Grafana screenshot](https://github.com/codex-storage/nim-chroprof/blob/gh-pages/assets/images/profiling-slowdown.png?raw=true)
+
+the cumulative chart on the left shows that two procs (with the bottom one 
+turning out to be a child of the top one) were dominating execution time at a 
+certain point, whereas the one on the right shows a number of peaks and anomalies
+which, in the context of a bug, may help identify the cause.
+
+## Limitations
+
+* Nested `waitFor` calls are not supported;
+* Prometheus metrics only work with `refc` because nim-metrics only works with `refc`;
+* the Prometheus metrics collector can only be enabled for one event loop; i.e.,
+  you cannot have multiple loops in different threads publishing metrics to Prometheus.