diff --git a/docs/overview/examples.mdx b/docs/overview/examples.mdx
index 69ae876c1..fc81bf413 100644
--- a/docs/overview/examples.mdx
+++ b/docs/overview/examples.mdx
@@ -6,10 +6,10 @@ title: "Examples"
## Create an incident only if the customer is on Enterprise tier
-In this example we will utilze:
+In this example we will utilize:
1. Datadog for monitoring
-2. OpsGenie for incident managment
+2. OpsGenie for incident management
3. A postgres database that stores the customer tier.
This example consists of two steps:
@@ -45,7 +45,7 @@ alert:
type: opsgenie
config: " {{ providers.opsgenie-prod }} "
with:
- message: "A new alert on enteprise customer ( {{ steps.check-if-customer-is-enterprise.results[1] }} )"
+ message: "A new alert on enterprise customer ( {{ steps.check-if-customer-is-enterprise.results[1] }} )"
```
## Send a slack message for every Cloudwatch alarm
diff --git a/docs/overview/introduction.mdx b/docs/overview/introduction.mdx
index b52681e87..e873e9654 100644
--- a/docs/overview/introduction.mdx
+++ b/docs/overview/introduction.mdx
@@ -1,6 +1,6 @@
---
title: "Introduction"
-description: "Keep is an open-source alert management and automation tool that provides everything you need to collect, enrich and manange alerts effectively."
+description: "Keep is an open-source alert management and automation tool that provides everything you need to collect, enrich and manage alerts effectively."
---
You can start using Keep by logging in to the [platform](https://platform.keephq.dev).
diff --git a/docs/overview/keyconcepts.mdx b/docs/overview/keyconcepts.mdx
index 07c2193fe..77cd21758 100644
--- a/docs/overview/keyconcepts.mdx
+++ b/docs/overview/keyconcepts.mdx
@@ -23,7 +23,7 @@ A Provider can either push alerts into Keep, or Keep can pull alerts from the Pr
#### Push alerts to Keep (Manual)
You can configure your alert source to push alerts into Keep.
-For example, consider Promethues. If you want to push alerts from Promethues to Keep, you'll need to configure Promethues Alertmanager to send the alerts to
+For example, consider Prometheus. If you want to push alerts from Prometheus to Keep, you'll need to configure Prometheus Alertmanager to send the alerts to
'https://api.keephq.dev/alerts/event/prometheus' using API key authentication. Each Provider implements Push mechanism and is documented under the specific Provider page.
#### Push alerts to Keep (Automatic)
diff --git a/docs/providers/adding-a-new-provider.mdx b/docs/providers/adding-a-new-provider.mdx
index d81520cda..e2541e95b 100644
--- a/docs/providers/adding-a-new-provider.mdx
+++ b/docs/providers/adding-a-new-provider.mdx
@@ -2,7 +2,7 @@
title: "Adding a new Provider"
sidebarTitle: "Adding a New Provider"
---
-Under contstruction
+Under construction
### Basics
@@ -192,7 +192,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
)
# else, if we are in an event context, use the event fingerprint
elif self.context_manager.event_context:
- # TODO: map all casses event_context is dict and update them to the DTO
+ # TODO: map all cases event_context is dict and update them to the DTO
# and remove this if statement
if isinstance(self.context_manager.event_context, dict):
fingerprint = self.context_manager.event_context.get("fingerprint")
@@ -446,7 +446,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
@staticmethod
def parse_event_raw_body(raw_body: bytes) -> bytes:
"""
- Parse the raw body of an event and create an ingestable dict from it.
+ Parse the raw body of an event and create an ingestible dict from it.
For instance, in parseable, the "event" is just a string
> b'Alert: Server side error triggered on teststream1\nMessage: server reporting status as 500\nFailing Condition: status column equal to abcd, 2 times'
@@ -459,7 +459,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
raw_body (bytes): The raw body of the incoming event (/event endpoint in alerts.py)
Returns:
- dict: Ingestable event
+ dict: Ingestible event
"""
return raw_body
diff --git a/docs/providers/documentation/auth0-provider.mdx b/docs/providers/documentation/auth0-provider.mdx
index 8eb53bc4e..0ea5aa8b0 100644
--- a/docs/providers/documentation/auth0-provider.mdx
+++ b/docs/providers/documentation/auth0-provider.mdx
@@ -51,6 +51,6 @@ workflow:
audience: "https://api.example.com"
grant_type: "client_credentials"
-##Usefull Links
+## Useful Links
-[Auth0 API Documentation](https://auth0.com/docs/api)
-[Auth0 as an authentication method for keep](https://docs.keephq.dev/deployment/authentication/auth0-auth)
\ No newline at end of file
diff --git a/docs/workflows/state.mdx b/docs/workflows/state.mdx
index c06e46f34..3ef54c15d 100644
--- a/docs/workflows/state.mdx
+++ b/docs/workflows/state.mdx
@@ -8,7 +8,7 @@ Keep State Manager is currently used for:
2. Track alerts over time
3. Previous runs context
-State is currently being saved as a JSON file under `./state/keepstate.json`, a path that can be overriden by setting the `KEEP_STATE_FILE` environment variable.
+State is currently being saved as a JSON file under `./state/keepstate.json`, a path that can be overridden by setting the `KEEP_STATE_FILE` environment variable.
## Example
One of the usages for Keep's state mechanism is throttling, see [One Until Resolved](/workflows/throttles/one-until-resolved) Keep handles it for you behind the scenes so you can use it without doing any further modifications.
@@ -44,4 +44,4 @@ An example for a simple state file:
Keep's roadmap around state (great first issues):
- Saving state in a database.
- Hosting state in buckets (AWS, GCP and Azure -> read/write).
-- Enriching state with more context so throttling mechanism would be flexer.
+- Enriching state with more context so throttling mechanism would be flexible.
diff --git a/docs/workflows/syntax/basic-syntax.mdx b/docs/workflows/syntax/basic-syntax.mdx
index 143dff685..b7ea0f28c 100644
--- a/docs/workflows/syntax/basic-syntax.mdx
+++ b/docs/workflows/syntax/basic-syntax.mdx
@@ -4,7 +4,7 @@ description: "At Keep, we view alerts as workflows, which consist of a series of
---
## Full Example
```yaml title=examples/raw_sql_query_datetime.yml
-# Notify if a result queried from the DB is above a certain thershold.
+# Notify if a result queried from the DB is above a certain threshold.
workflow:
id: raw-sql-query
description: Monitor that time difference is no more than 1 hour
@@ -52,7 +52,7 @@ workflow:
- Metadata (id, description. owners and tags will be added soon)
- `steps` - list of steps
- `actions` - list of actions
-- `on-failure` - a conditionless action used in case of an alert failure
+- `on-failure` - an action with no condition used in case of an alert failure
### Provider
```yaml
@@ -126,5 +126,5 @@ on-failure:
config: " {{ providers.slack-demo }} "
```
-On-failure is actually a condtionless `Action` used to notify in case the alert failed with an exception.
+On-failure is actually an `Action` with no condition used to notify in case the alert failed with an exception.
The provider is passed a `message` (string) to it's `notify` function.
diff --git a/docs/workflows/syntax/context-syntax.mdx b/docs/workflows/syntax/context-syntax.mdx
index 4cf854780..62cff7253 100644
--- a/docs/workflows/syntax/context-syntax.mdx
+++ b/docs/workflows/syntax/context-syntax.mdx
@@ -1,6 +1,6 @@
---
title: "Working with context"
-sidebarTitle: "Content Syntax"
+sidebarTitle: "Context Syntax"
description: "Keep uses [Mustache](https://mustache.github.io/) syntax to inject context at runtime, supporting functions, dictionaries, lists, and nested access."
---
@@ -12,7 +12,7 @@ Here are some examples:
- `keep.first({{ steps.this.results }})` - First result (equivalent to the previous example)
- `{{ steps.step-id.results[0][0] }}` - First item of the first result
-If you have suggestions/improvments/bugs for Keep's syntax, please [open feature request](https://github.com/keephq/keep/issues/new?assignees=&labels=&template=feature_request.md&title=) and get eternal glory.
+If you have suggestions/improvements/bugs for Keep's syntax, please [open feature request](https://github.com/keephq/keep/issues/new?assignees=&labels=&template=feature_request.md&title=) and get eternal glory.
### Special context
diff --git a/docs/workflows/syntax/foreach-syntax.mdx b/docs/workflows/syntax/foreach-syntax.mdx
index 310f7ceb0..0d8433dca 100644
--- a/docs/workflows/syntax/foreach-syntax.mdx
+++ b/docs/workflows/syntax/foreach-syntax.mdx
@@ -1,7 +1,7 @@
---
title: "Foreach"
sidebarTitle: "Foreach Syntax"
-description: "Foreach syntax add the flexability of running action per result instead of only once on all results."
+description: "Foreach syntax add the flexibility of running action per result instead of only once on all results."
---
## Usage
diff --git a/docs/workflows/throttles/one-until-resolved.mdx b/docs/workflows/throttles/one-until-resolved.mdx
index 6f36874bd..491c0b7bc 100644
--- a/docs/workflows/throttles/one-until-resolved.mdx
+++ b/docs/workflows/throttles/one-until-resolved.mdx
@@ -8,7 +8,7 @@ For example:
1. Alert executed and action were triggered as a result -> the alert status is now "Firing".
2. Alert executed again and action should be triggered -> the action will be throttled.
3. Alert executed and no action is required -> the alert status is now "Resolved".
-4. Alert exectued and action were triggered -> the action is triggered
+4. Alert executed and action were triggered -> the action is triggered
## How to use