Merge pull request #10 from NucleusEngineering/romanseibel-patch-3

Update tutorial.neos.md minor edits to Module 4

Author: helloworlddan

.journey/tutorial.neos.md

@@ -1060,7 +1060,7 @@ historic metrics data is available for later exercises. Use
 requests per minute for the next 15 minutes to generate a base load without
 triggering
 [quota limits](https://cloud.google.com/vertex-ai/generative-ai/docs/quotas) of
-the Gemini API.:
+the Gemini API:
 
 ```bash
 hey -z 15m -c 3 -q 1 $(gcloud run services describe jokes --format 'value(status.url)')
@@ -1228,8 +1228,7 @@ there and start the new SLO creation wizard. Define an SLO, that:
 - This means that your error budget is 1% of all requests or 14 minutes per day
   if your traffic is equally distributed throughout the day.
 
-Finally, also create an alert that will notify you in case a fast-burn of your
-error budget gets detected. Create an new alert, that:
+Finally, also create an alert that will notify you in case a [fast-burn](https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/alerting-on-budget-burn-rate#burn-rates) of yourerror budget gets detected. Create an new alert, that:
 
 - uses a **look back duration of 5 minutes**
 - breaches with a **fast-burn threshold 10(x baseline)**
@@ -1256,8 +1255,8 @@ Cloud Run comes with a built-in traffic control plane, which lets operators
 programmatically assign traffic to individual revisions of the same service.
 This allows you to deploy new changes to your service with none or only
 single-digit percentage traffic routed to them. Once you've slowly gained
-confidence in your new revision you can gradually increase traffic until you r
-each 100% of traffic on the new revision and your rollout is complete. This
+confidence in your new revision you can gradually increase traffic until you reach 
+100% of traffic on the new revision and your rollout is complete. This
 strategy is commonly referred to as a
 [canary release](https://cloud.google.com/deploy/docs/deployment-strategies/canary).