diff --git a/.claude/settings.json b/.claude/settings.json
new file mode 100644
index 0000000..05ad30e
--- /dev/null
+++ b/.claude/settings.json
@@ -0,0 +1,15 @@
+{
+  "permissions": {
+    "rules": [
+      "Edit(docs/**)",
+      "Edit(*.mdx)",
+      "Edit(*.md)", 
+      "Edit(docs.json)",
+      "Read(**)",
+      "Bash(git *)",
+      "Bash(gh *)",
+      "Bash(npm *)"
+    ],
+    "mode": "acceptEdits"
+  }
+}
\ No newline at end of file
diff --git a/.claude/workflow.md b/.claude/workflow.md
new file mode 100644
index 0000000..94d41e5
--- /dev/null
+++ b/.claude/workflow.md
@@ -0,0 +1,18 @@
+# Claude Code GitHub Issue Workflow
+
+## Workflow Steps
+1. Read GitHub issue content using `gh issue view <issue_number>`
+2. Create new branch: `git checkout -b feature/issue-<issue_number>`
+3. Implement the requested changes
+4. Commit changes with appropriate message
+5. Push branch: `git push -u origin feature/issue-<issue_number>`
+6. Create PR: `gh pr create --title "..." --body "..."`
+7. Comment on original issue with PR link
+
+## Usage
+When given an issue number, Claude Code will:
+- Extract the issue requirements
+- Create and switch to a new branch
+- Implement the requested feature/fix
+- Push the branch and create a PR
+- Link back to the original issue
\ No newline at end of file
diff --git a/.github/workflows/claude-code.yml b/.github/workflows/claude-code.yml
new file mode 100644
index 0000000..b924dda
--- /dev/null
+++ b/.github/workflows/claude-code.yml
@@ -0,0 +1,60 @@
+name: Claude Code Issue Automation
+
+on:
+  issues:
+    types: [opened, edited]
+  issue_comment:
+    types: [created]
+
+jobs:
+  claude-respond:
+    if: contains(github.event.issue.body, '@claude') || contains(github.event.comment.body, '@claude')
+    runs-on: ubuntu-latest
+    
+    permissions:
+      contents: write
+      issues: write
+      pull-requests: write
+    
+    steps:
+    - uses: actions/checkout@v4
+    
+    - name: Run Claude Code
+      env:
+        ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      run: |
+        # Install Claude Code
+        curl -fsSL https://claude.ai/install.sh | bash
+        
+        # Get issue content
+        ISSUE_BODY="${{ github.event.issue.body || github.event.comment.body }}"
+        ISSUE_NUMBER="${{ github.event.issue.number }}"
+        
+        # Create branch name
+        BRANCH_NAME="claude/issue-${ISSUE_NUMBER}"
+        
+        # Configure git
+        git config user.name "Claude Code Bot"
+        git config user.email "claude@anthropic.com"
+        
+        # Create and checkout new branch
+        git checkout -b "$BRANCH_NAME"
+        
+        # Run Claude Code with the issue content
+        claude -p "Work on GitHub issue #${ISSUE_NUMBER}: ${ISSUE_BODY}"
+        
+        # Push branch if changes were made
+        if ! git diff --quiet HEAD; then
+          git push -u origin "$BRANCH_NAME"
+          
+          # Create PR
+          gh pr create \
+            --title "Fix issue #${ISSUE_NUMBER}" \
+            --body "Addresses #${ISSUE_NUMBER}\n\n🤖 Generated with Claude Code" \
+            --head "$BRANCH_NAME" \
+            --base main
+            
+          # Comment on original issue
+          gh issue comment ${ISSUE_NUMBER} --body "PR created: $(gh pr view --json url --jq .url)"
+        fi
\ No newline at end of file
diff --git a/cli/using-git.mdx b/cli/using-git.mdx
index 73fa83a..ac7a8c4 100644
--- a/cli/using-git.mdx
+++ b/cli/using-git.mdx
@@ -4,7 +4,7 @@ description: 'Learn how to use Git with Checkly'
 sidebarTitle: 'Using Git'
 ---
 
-
+## Using Git
 The CLI can attach git metadata like `branch`, `commit sha`, `owner` and more when executing the `test --record` and `deploy` commands. This way you can keep track of 
 your test sessions and deployed resources in the UI and cross-reference them with any updates to your code.
 
diff --git a/constructs/structure.mdx b/constructs/structure.mdx
index b7eff62..83aaaf5 100644
--- a/constructs/structure.mdx
+++ b/constructs/structure.mdx
@@ -5,7 +5,6 @@ sidebarTitle: Structure
 ---
 
 
-The example below shows how a typical Checkly CLI project is organized. Most files, directories and paths are conventions you can tweak to your liking using `import` / `require` and setting `glob` patterns.
 
 ## Directories and files
 
diff --git a/docs/communicate/alerts/overview.mdx b/docs/communicate/alerts/overview.mdx
index d4073ed..94f60b5 100644
--- a/docs/communicate/alerts/overview.mdx
+++ b/docs/communicate/alerts/overview.mdx
@@ -12,44 +12,39 @@ Checkly provides sophisticated alerting and retry mechanisms to keep you informe
 
 Checkly alerts you when your checks transition between states such as passing to failing, degraded performance, or recovery. The system is designed to provide actionable notifications while minimizing noise through intelligent retry strategies and flexible escalation policies.
 
-![Checkly alerting dashboard overview](/images/docs/images/alerting/alerting-overview.png)
+![Checkly alerting dashboard overview](/images/alerts-dash.png)
 
-<CardGroup cols={2}>
-<Card title="Smart alerting" icon="bell">
+### Benefits
+**Smart alerting:**
 - Configurable alert thresholds and escalation
 - Multiple notification channels and integrations
 - Location-based failure filtering
 - SSL certificate expiration monitoring
-</Card>
 
-<Card title="Retry strategies" icon="refresh">
+**Retry strategies:**
 - Reduce false positives with intelligent retries
 - Fixed, linear, and exponential backoff options
 - Location-based and network-specific retry logic
 - Configurable retry limits and timeouts
-</Card>
-</CardGroup>
 
 ## Core Alerting Components
 
-### 1. Alert Settings
+### 1. Escalation Strategies
 Control **when** and **how often** you receive notifications with threshold alerting:
 
-<CardGroup cols={2}>
-<Card title="Escalation strategies" icon="stairs">
+## Escalation strategies
+
 - **Run-based**: Alert after consecutive failures
 - **Time-based**: Alert if failing for specific duration
 - **Location threshold**: Only alert when % of locations fail
 - **Immediate**: Alert on first failure
-</Card>
 
-<Card title="Reminder configuration" icon="clock">
+## Reminder configuration
+
 - Multiple reminder intervals
 - Automatic cancellation on recovery
 - Customizable reminder frequency
 - Escalation to different teams
-</Card>
-</CardGroup>
 
 ### 2. Alert Channels
 Determine **how** alert notifications reach your team:
diff --git a/docs/communicate/dashboards/customization.mdx b/docs/communicate/dashboards/customization.mdx
index dcc92a2..f4f11db 100644
--- a/docs/communicate/dashboards/customization.mdx
+++ b/docs/communicate/dashboards/customization.mdx
@@ -6,7 +6,9 @@ sidebarTitle: 'Customization'
 
 Dashboard customization allows you to create professional, branded status displays that align with your organization's visual identity and communication needs.
 
+
 ## Look and Feel
+![Dashboard customization](/images/dashboard-look.png)
 
 ### Logo
 Upload your brand logo to personalize the dashboard header. The logo image supports PNG, JPG, and SVG formats with a maximum size of 1024px×1024px.
@@ -36,6 +38,8 @@ Display performance metrics on your dashboard:
 
 ## Advanced CSS Customization
 
+![Dashboard customization](/images/dashboard-custom-css.png)
+
 ### CSS Editor and Tools
 For Team and Enterprise plans, unlock complete design control:
 
diff --git a/docs/communicate/dashboards/domain-configuration.mdx b/docs/communicate/dashboards/domain-configuration.mdx
index 5431925..20176e2 100644
--- a/docs/communicate/dashboards/domain-configuration.mdx
+++ b/docs/communicate/dashboards/domain-configuration.mdx
@@ -20,6 +20,9 @@ https://{random-id}.checkly-dashboards.com
 https://a1b2c3d4-e5f6-7890-abcd-ef1234567890.checkly-dashboards.com
 ```
 
+You can also use a custom subdomain to make your dashboard more recognizable.
+
+![Custom subdomain](/images/dashboard-custom-url.png)
 
 ```text
 # Custom subdomain format
@@ -38,6 +41,8 @@ Custom subdomains must be unique across all Checkly users. Choose something spec
 ### Full Custom Domain Configuration
 Use your own domain for maximum branding control and professional appearance:
 
+![Custom domain](/images/dashboard-custom-domain.png)
+
 <Steps>
 <Step title="Domain Configuration">
 Add your custom domain in the dashboard settings
diff --git a/docs/communicate/dashboards/overview.mdx b/docs/communicate/dashboards/overview.mdx
index 0e5353e..5fd9e3f 100644
--- a/docs/communicate/dashboards/overview.mdx
+++ b/docs/communicate/dashboards/overview.mdx
@@ -6,15 +6,6 @@ sidebarTitle: 'Overview'
 
 Dashboards provide a detailed way to communicate the status and performance of your monitoring checks and services to internal and external audiences. Create professional, branded status displays for customers, internal teams, or specific stakeholders.
 
-## Metrics To Display
-Comprehensive performance data for transparency and accountability:
-
-| Metric | Time Period | Description | Use Case |
-|--------|-------------|-------------|----------|
-| **Availability** | 24h, 7d, 30d | Percentage of successful checks | SLA reporting |
-| **P95 Response Time** | 24h, 7d, 30d | 95th percentile response time | Performance baseline |
-| **P99 Response Time** | 24h, 7d, 30d | 99th percentile response time | Performance outliers |
-| **Uptime Statistics** | Historical | Long-term reliability data | Trust building |
 
 ## Setting Up Your Dashboard
 
@@ -92,3 +83,13 @@ Protected dashboards work with both access methods:
 <Warning>
 Remember that dashboards are public by default. Always review which checks and data you're exposing before sharing dashboard URLs with external audiences.
 </Warning>
+
+## Metrics To Display
+Comprehensive performance data for transparency and accountability:
+
+| Metric | Time Period | Description | Use Case |
+|--------|-------------|-------------|----------|
+| **Availability** | 24h, 7d, 30d | Percentage of successful checks | SLA reporting |
+| **P95 Response Time** | 24h, 7d, 30d | 95th percentile response time | Performance baseline |
+| **P99 Response Time** | 24h, 7d, 30d | 99th percentile response time | Performance outliers |
+| **Uptime Statistics** | Historical | Long-term reliability data | Trust building |
diff --git a/docs/communicate/maintenance-windows/overview.mdx b/docs/communicate/maintenance-windows/overview.mdx
index ad3847c..2466281 100644
--- a/docs/communicate/maintenance-windows/overview.mdx
+++ b/docs/communicate/maintenance-windows/overview.mdx
@@ -13,18 +13,18 @@ Maintenance windows allow you to schedule planned downtime for your services, pr
 
 ## Creating a maintenance window 
 
-Adding a maintenance window is simple. Navigate to the maintenance windows overview indicated by the wrench icon on the 
-menu and click "create new". You're now on the maintenance window editor.
-
-![maintenance window editor](/images/docs/images/maintenance-windows/maintenance-window-editor.png)
+Navigate to the Maintenance Windows page indicated by the wrench icon on the menu. Then click "create new" in the top right corner.
 
 After giving your window an appropriate name, the core options you have are:
 
 ### Setting a schedule
 
+![Maintenance window schedule](/images/maintenance-schedule-3.png)
+
 Set your preferred starting date and time for your maintenance window. **Note that all times are in UTC.** 
 
-### Setting repeats
+#### Setting repeats
+
 If your maintenance window repeats at a certain cadence, toggle the **repeat** option. Here you can set
 
 1. The amount of repetitions.
@@ -34,7 +34,9 @@ If your maintenance window repeats at a certain cadence, toggle the **repeat** o
 > If you schedule a window on the 31st and add a **monthly repeat cycle**, your schedule will also activate on
 > the 30th of the relevant months and the 28th or 29th of February depending on the leap year.
 
-## Adding checks and check groups
+### Adding checks and check groups
+
+![Maintenance window checks](/images/maintenance-checks-2.png)
 
 You need to select which checks and/or check groups are targeted by your maintenance window. You do this by:
  
diff --git a/docs/detect/uptime-monitoring/url-monitors/creating-your-first-url-monitor.mdx b/docs/detect/uptime-monitoring/url-monitors/creating-your-first-url-monitor.mdx
index 3d26745..820bf52 100644
--- a/docs/detect/uptime-monitoring/url-monitors/creating-your-first-url-monitor.mdx
+++ b/docs/detect/uptime-monitoring/url-monitors/creating-your-first-url-monitor.mdx
@@ -6,8 +6,8 @@ sidebarTitle: 'Creating Your First Monitor'
 
 This guide walks you through creating your first URL monitor to check the availability and performance of your websites, APIs, or any HTTP-based service.
 
-
-## Creating in the UI
+<Tabs>
+<Tab title="Create from UI">
 
 Each URL monitor is defined by its request configuration, which includes the target URL and how its availability and performance should be validated.
 
@@ -26,7 +26,9 @@ To validate the response, you can configure:
 * **Alerting:** Configure comprehensive alerting and notification rules. 
 
 </Accordion>
-## Creating As Code
+
+</Tab>
+<Tab title="Create from Code">
 
 With the [Checkly CLI](/cli/overview), you can define URL monitors in TypeScript or JavaScript and manage them as code. See [CLI configuration](/docs/detect/uptime-monitoring/cli-configuration) for comprehensive examples and advanced patterns.
 
@@ -73,6 +75,9 @@ new UrlMonitor('hello-url-1', {
 
 See the full [Url monitor construct reference](/constructs/url-monitor) for more context.
 
+</Tab>
+</Tabs>
+
 
 
 
diff --git a/docs/detect/uptime-monitoring/url-monitors/overview.mdx b/docs/detect/uptime-monitoring/url-monitors/overview.mdx
index d17825e..49519a8 100644
--- a/docs/detect/uptime-monitoring/url-monitors/overview.mdx
+++ b/docs/detect/uptime-monitoring/url-monitors/overview.mdx
@@ -7,32 +7,179 @@ sidebarTitle: Overview
 **Monitoring as Code**: Learn more about the [URL Monitor Construct](/constructs/url-monitor).
 </Tip>
 
-Use URL monitors to track the availability of your HTTP-based services. They send HTTP requests to specified URLs and check for successful responses and acceptable response times.
+URL monitors track the availability of your HTTP-based services by sending requests to specified URLs and validating responses, performance, and content.
 
-**Typical use cases include:**
+
+
+<Accordion title="Typical Use Cases Include">
 
 * Ensuring your marketing site returns a 200 OK
 * Verifying your documentation site loads quickly
 * Checking that your SSL certificate is still valid
 * Confirming that a public pricing endpoint is reachable for customers
 
+</Accordion>
+
+## Configuration Options
+
+### Basic Setup
+
+Monitor any URL by specifying the endpoint you want to track. You can configure the HTTP method, add request headers, and set SSL/redirect options:
+
+<Frame>
+  <img src="/images/url-monitor-entry.png" alt="URL monitor setup interface showing HTTP method selection, URL input field, and options for Skip SSL and Follow redirects" />
+</Frame>
+
+### Assertions
+
+Use assertions to validate the status code of your URL request. When one or more assertions fail, an alert is triggered:
+
+<Frame>
+  <img src="/images/url-monitor-assertions.png" alt="URL monitor assertions interface showing status code configuration" />
+</Frame>
+
+**Status Code**
+Verify your endpoint returns the expected HTTP status code using the comparison dropdown. Choose from equals, not equals, greater than, or less than.
+
+
+### Response Time Limits
+
+Set performance thresholds to ensure your application meets speed requirements:
+
+<Frame>
+  <img src="/images/url-monitor-response-times.png" alt="URL monitor response time limits interface showing degraded and failed thresholds" />
+</Frame>
+
+**Degraded After**: Time threshold (in milliseconds) after which the check is marked as degraded but not failed. Use for performance warnings without triggering failure alerts.
+
+**Failed After**: Time threshold after which the check fails completely. Use for hard performance limits where slow responses should trigger alerts.
+
+### Frequency
+
+Determine how often your monitors run. Unlike Synthetic Monitors, URL Monitors do not consume "Checks" and can run at any frequency available to your plan:
+
+<Frame>
+  <img src="/images/url-monitor-frequency.png" alt="URL monitor frequency selection interface showing available check intervals" />
+</Frame>
+
+Choose a frequency that balances monitoring coverage with resource usage. Higher frequencies provide faster detection but may not be necessary for all services.
+
+### Scheduling Strategy
+
+Choose when and how your checks run across multiple locations:
+
+<Frame>
+  <img src="/images/url-monitor-scheduling.png" alt="URL monitor scheduling strategy interface showing round robin vs fixed schedule options" />
+</Frame>
+
+**Round Robin** (Default): Checks run from one random location each interval. Most cost-effective option for general availability monitoring.
+
+**Fixed Schedule**: Checks run from all selected locations simultaneously. Higher consumption but provides immediate global visibility for critical services.
+
+### Locations
+
+Select from Checkly's global monitoring locations to test your URLs from different regions:
+
+<Frame>
+  <img src="/images/url-monitor-locations.png" alt="URL monitor locations selection interface showing global monitoring locations" />
+</Frame>
+
+Choose 2-3 locations that best represent your user base for optimal monitoring coverage. 
+
+See [Locations](/docs/introduction/concepts/locations) for the complete list of available regions and guidance on location selection.
+
+<Info>
+**Private Locations**: Run checks from your own infrastructure to monitor internal applications, check services behind firewalls, or maintain data residency compliance. [Set up Private Locations →](/docs/detect/private-locations/overview)
+</Info>
+
+### Retries
+
+Select the retry strategy to determine how failed checks are retried:
+
+<Frame>
+  <img src="/images/url-monitor-retries.png" alt="URL monitor retries interface showing retry strategy options" />
+</Frame>
+
+| Strategy | Description |
+|----------|-------------|
+| **None** | No retries - fail immediately on first failure for fastest detection |
+| **Fixed** | Retry a specific number of times with consistent intervals between attempts |
+| **Linear** | Increase retry delay linearly with each attempt to avoid overwhelming failed services |
+| **Exponential** | Double the retry delay with each attempt for maximum protection against service overload |
+
+### Alert Settings
+
+Configure notifications for your team:
+
+<Frame>
+  <img src="/images/url-monitor-alert.png" alt="URL monitor alert settings interface showing notification configuration options" />
+</Frame>
+
+#### Notification Scope
+
+Choose how alerts are configured for this monitor:
+
+| Option | Description |
+|--------|-------------|
+| **Use global account notification settings** | Inherit notification preferences from Global Notification Settings |
+| **Use specific notification settings** | Configure alert behavior exclusively for this check |
+
+#### Escalation Rules
+
+Control when alerts are triggered:
+
+**Primary Trigger** (Choose one):
+- **When a check has failed X time(s)**: Sends alert after specified consecutive failures
+- **When a check is failing for more than Y minutes**: Sends alert if failure duration exceeds threshold
+
+**Additional Condition** (Optional):
+- **When a check is failing in Z% of locations**: Only applies to checks running in parallel across multiple locations
+
+#### Reminders
+
+Configure follow-up alerts after initial failure notification:
 
-## Alerting
+| Setting | Description |
+|---------|-------------|
+| **Maximum reminders** | Number of follow-up alerts (0 = no reminders) |
+| **Reminder interval** | Time between reminders (only if maximum reminders > 0) |
 
-You can configure alerts to be triggered when a a URL goes down, returns an unexpected status code, or responds too slowly.
+#### Alert Channels
 
-URL monitors can notify you via all available alerting channels for your plan. 
+Define where notifications are sent when checks fail or recover. Additional channels can be configured in global notification settings.
 
-See more here: [Alerting](/docs/communicate/alerts/overview).
+**Alert Types** (per channel):
+- ✅ **Success/Recovery**: Check has recovered from failure
+- ⚠ **Warning**: Check is degraded but not failed  
+- ❌ **Failure**: Check has failed
+- 🔒 **Locked/Restricted**: Channel access limited
 
-## Locations
+<Note>
+**Global Alert Settings**: By default, monitors inherit your account's notification preferences. Select "Use specific notification settings" to customize alerts for individual monitors.
+</Note>
 
-You can configure URL monitors to run from multiple locations around the world. This helps you ensure your application is available from all parts of the world.
+## Best Practices
 
-See more here: [Locations](/docs/introduction/concepts/locations).
+<Accordion title="Choosing Frequencies">
+- **Critical services**: Every 1-2 minutes
+- **Important services**: Every 5 minutes  
+- **Standard services**: Every 10-15 minutes
+- **Background services**: Every 30 minutes to 1 hour
+</Accordion>
 
-## Scheduling & Frequency
+<Accordion title="Location Selection">
+- Choose 2-3 locations covering your user base
+- Include at least one location near your infrastructure
+- Consider regulatory requirements for data residency
+</Accordion>
 
-You can configure the frequency of your URL monitors to run at a frequency that is appropriate for the service being monitored. Unlike Synthetic Monitors, URL Monitors do not consume "Checks" and can be run on any frequency available to your plan.
+<Accordion title="Assertion Strategy">
+- Always check status codes
+- Include content assertions for critical functionality
+- Set appropriate response time thresholds
+- Test assertions thoroughly before deployment
+</Accordion>
 
-See more here: [Scheduling](/docs/introduction/concepts/scheduling).
\ No newline at end of file
+<Accordion title="Implement as a Construct">
+For monitoring as code workflows, use the URL Monitor construct to version control your monitoring configuration and deploy alongside your application code. [Learn about URL Monitor Construct →](/constructs/url-monitor)
+</Accordion>
diff --git a/docs/introduction/quickstart.mdx b/docs/introduction/quickstart.mdx
index 8c46e30..2099659 100644
--- a/docs/introduction/quickstart.mdx
+++ b/docs/introduction/quickstart.mdx
@@ -7,7 +7,12 @@ sidebarTitle: 'Quickstart'
 import CliProjectInit from '/snippets/cli-project-init.mdx';
 import CliAuth from '/snippets/cli-auth.mdx';
 
-This  guide will walk you through creating your first browser check using the Checkly CLI. You'll learn how to set up monitoring for a web application, configure alerts, and deploy your checks to run continuously.
+This guide will walk you through creating your first browser check with Checkly. Choose your preferred approach:
+
+<Tabs>
+<Tab title="Monitoring as Code">
+
+Get started with Checkly using the CLI and code-first approach. You'll learn how to set up monitoring for a web application, configure alerts, and deploy your checks to run continuously.
 
 <Accordion title="Prerequisites">
 - Node.js 16+ installed
@@ -185,4 +190,88 @@ Now that you have your first browser check running, explore these advanced featu
 - **Use Environment Variables**: Keep sensitive data secure
 - **Tag Your Checks**: Organize monitoring by feature or team
 
-Congratulations! You've successfully set up automated browser monitoring with Checkly. Your application is now being continuously monitored from multiple global locations.
\ No newline at end of file
+Congratulations! You've successfully set up automated browser monitoring with Checkly. Your application is now being continuously monitored from multiple global locations.
+
+</Tab>
+<Tab title="Starting in the UI">
+
+Get started with Checkly using the web interface. This approach is perfect for getting up and running quickly without any local setup.
+
+<Accordion title="Prerequisites">
+- A Checkly account (sign up at [checklyhq.com](https://checklyhq.com))
+- The URL of a website you want to monitor
+</Accordion>
+
+<Steps>
+<Step title="Create Your First Check">
+1. **Log in** to your Checkly dashboard at [app.checklyhq.com](https://app.checklyhq.com)
+2. **Click "Create Check"** from the main dashboard
+3. **Choose "Browser Check"** for comprehensive website monitoring
+4. **Enter your website URL** (e.g., `https://your-website.com`)
+5. **Give your check a name** like "Homepage Monitor"
+</Step>
+
+<Step title="Configure Basic Settings">
+Configure your check settings:
+
+- **Locations**: Select 2-3 global locations (e.g., US East, EU West, Asia Pacific)
+- **Frequency**: Start with every 5 minutes for critical pages
+- **Tags**: Add tags like `production` or `homepage` for organization
+
+<Note>
+For your first check, the default settings work well. You can always adjust them later.
+</Note>
+</Step>
+
+<Step title="Set Up Alerts">
+Configure who gets notified when issues are detected:
+
+1. **Click "Alert Settings"** in the check configuration
+2. **Add your email address** for notifications
+3. **Choose alert conditions**: 
+   - Alert after 1 failure (for critical pages)
+   - Alert after 2 failures (for less critical pages)
+4. **Set recovery notifications** to know when issues are resolved
+</Step>
+
+<Step title="Test and Save">
+Before activating your check:
+
+1. **Click "Test Check"** to run it once and verify it works
+2. **Review the results** to ensure your website loads correctly
+3. **Check for any errors** in the console or network tabs
+4. **Click "Save and Activate"** to start continuous monitoring
+</Step>
+
+<Step title="View Results">
+Once your check is active:
+
+1. **Visit your dashboard** to see real-time results
+2. **Check the results page** for detailed performance metrics
+3. **Review screenshots** and timing information
+4. **Set up additional checks** for other critical pages
+</Step>
+</Steps>
+
+## Next Steps
+
+Now that you have your first check running:
+
+- **Add API Checks**: Monitor your backend services and APIs
+- **Create Check Groups**: Organize related checks together
+- **Set up Status Pages**: Share uptime information with users
+- **Explore Integrations**: Connect with Slack, PagerDuty, or other tools
+
+## Upgrading to Monitoring as Code
+
+As your monitoring needs grow, consider upgrading to our CLI approach:
+
+- **Version Control**: Keep your monitoring configuration in Git
+- **Team Collaboration**: Review changes through pull requests  
+- **CI/CD Integration**: Deploy monitoring alongside your applications
+- **Advanced Scripting**: Write custom Playwright tests for complex flows
+
+Ready to make the switch? Check out the **Monitoring as Code** tab above!
+
+</Tab>
+</Tabs>
\ No newline at end of file
diff --git a/images/alerts-dash.png b/images/alerts-dash.png
new file mode 100644
index 0000000..06a7074
Binary files /dev/null and b/images/alerts-dash.png differ
diff --git a/images/alerts.png b/images/alerts.png
new file mode 100644
index 0000000..bc4b7fa
Binary files /dev/null and b/images/alerts.png differ
diff --git a/images/api-assertions.png b/images/api-assertions.png
new file mode 100644
index 0000000..48598e9
Binary files /dev/null and b/images/api-assertions.png differ
diff --git a/images/api-create-monitor.png b/images/api-create-monitor.png
new file mode 100644
index 0000000..7809b4b
Binary files /dev/null and b/images/api-create-monitor.png differ
diff --git a/images/api-setup.png b/images/api-setup.png
new file mode 100644
index 0000000..e8fb397
Binary files /dev/null and b/images/api-setup.png differ
diff --git a/images/dashboard-checks.png b/images/dashboard-checks.png
new file mode 100644
index 0000000..c537226
Binary files /dev/null and b/images/dashboard-checks.png differ
diff --git a/images/dashboard-css.png b/images/dashboard-css.png
new file mode 100644
index 0000000..19f4c7a
Binary files /dev/null and b/images/dashboard-css.png differ
diff --git a/images/dashboard-custom-css.png b/images/dashboard-custom-css.png
new file mode 100644
index 0000000..e275860
Binary files /dev/null and b/images/dashboard-custom-css.png differ
diff --git a/images/dashboard-custom-domain.png b/images/dashboard-custom-domain.png
new file mode 100644
index 0000000..77ac123
Binary files /dev/null and b/images/dashboard-custom-domain.png differ
diff --git a/images/dashboard-custom-url.png b/images/dashboard-custom-url.png
new file mode 100644
index 0000000..ec9632c
Binary files /dev/null and b/images/dashboard-custom-url.png differ
diff --git a/images/dashboard-incidents.png b/images/dashboard-incidents.png
new file mode 100644
index 0000000..860fa8e
Binary files /dev/null and b/images/dashboard-incidents.png differ
diff --git a/images/dashboard-look.png b/images/dashboard-look.png
new file mode 100644
index 0000000..f5aa94e
Binary files /dev/null and b/images/dashboard-look.png differ
diff --git a/images/dashboard-password.png b/images/dashboard-password.png
new file mode 100644
index 0000000..ce290fe
Binary files /dev/null and b/images/dashboard-password.png differ
diff --git a/images/dashboard.png b/images/dashboard.png
new file mode 100644
index 0000000..80b799c
Binary files /dev/null and b/images/dashboard.png differ
diff --git a/images/heartbeat-alert.png b/images/heartbeat-alert.png
new file mode 100644
index 0000000..e95f497
Binary files /dev/null and b/images/heartbeat-alert.png differ
diff --git a/images/heartbeat-period.png b/images/heartbeat-period.png
new file mode 100644
index 0000000..5039c09
Binary files /dev/null and b/images/heartbeat-period.png differ
diff --git a/images/heartbeat-ping.png b/images/heartbeat-ping.png
new file mode 100644
index 0000000..b32bdd2
Binary files /dev/null and b/images/heartbeat-ping.png differ
diff --git a/images/maintenance-checks-2.png b/images/maintenance-checks-2.png
new file mode 100644
index 0000000..b18e4b3
Binary files /dev/null and b/images/maintenance-checks-2.png differ
diff --git a/images/maintenance-checks.png b/images/maintenance-checks.png
new file mode 100644
index 0000000..a3a7b70
Binary files /dev/null and b/images/maintenance-checks.png differ
diff --git a/images/maintenance-schedule-2.png b/images/maintenance-schedule-2.png
new file mode 100644
index 0000000..9b360ba
Binary files /dev/null and b/images/maintenance-schedule-2.png differ
diff --git a/images/maintenance-schedule-3.png b/images/maintenance-schedule-3.png
new file mode 100644
index 0000000..a4049d9
Binary files /dev/null and b/images/maintenance-schedule-3.png differ
diff --git a/images/maintenance-schedule.png b/images/maintenance-schedule.png
new file mode 100644
index 0000000..d732eda
Binary files /dev/null and b/images/maintenance-schedule.png differ
diff --git a/images/private-locations-complete.png b/images/private-locations-complete.png
new file mode 100644
index 0000000..4a496d7
Binary files /dev/null and b/images/private-locations-complete.png differ
diff --git a/images/private-locations.png b/images/private-locations.png
new file mode 100644
index 0000000..96991cf
Binary files /dev/null and b/images/private-locations.png differ
diff --git a/images/tcp-assertions.png b/images/tcp-assertions.png
new file mode 100644
index 0000000..588a534
Binary files /dev/null and b/images/tcp-assertions.png differ
diff --git a/images/tcp-frequency.png b/images/tcp-frequency.png
new file mode 100644
index 0000000..d51d154
Binary files /dev/null and b/images/tcp-frequency.png differ
diff --git a/images/tcp-request.png b/images/tcp-request.png
new file mode 100644
index 0000000..b13a489
Binary files /dev/null and b/images/tcp-request.png differ
diff --git a/images/tcp-response.png b/images/tcp-response.png
new file mode 100644
index 0000000..22c1f95
Binary files /dev/null and b/images/tcp-response.png differ
diff --git a/images/traces.png b/images/traces.png
new file mode 100644
index 0000000..7c22d5e
Binary files /dev/null and b/images/traces.png differ
diff --git a/images/uptime-retries.png b/images/uptime-retries.png
new file mode 100644
index 0000000..0b0567b
Binary files /dev/null and b/images/uptime-retries.png differ
diff --git a/images/url-monitor-alert.png b/images/url-monitor-alert.png
new file mode 100644
index 0000000..2b561e3
Binary files /dev/null and b/images/url-monitor-alert.png differ
diff --git a/images/url-monitor-assertions.png b/images/url-monitor-assertions.png
new file mode 100644
index 0000000..5607164
Binary files /dev/null and b/images/url-monitor-assertions.png differ
diff --git a/images/url-monitor-entry.png b/images/url-monitor-entry.png
new file mode 100644
index 0000000..6fe1fd4
Binary files /dev/null and b/images/url-monitor-entry.png differ
diff --git a/images/url-monitor-frequency.png b/images/url-monitor-frequency.png
new file mode 100644
index 0000000..f0a7d79
Binary files /dev/null and b/images/url-monitor-frequency.png differ
diff --git a/images/url-monitor-locations.png b/images/url-monitor-locations.png
new file mode 100644
index 0000000..e4e3a08
Binary files /dev/null and b/images/url-monitor-locations.png differ
diff --git a/images/url-monitor-response-times.png b/images/url-monitor-response-times.png
new file mode 100644
index 0000000..0e9e1b7
Binary files /dev/null and b/images/url-monitor-response-times.png differ
diff --git a/images/url-monitor-retries.png b/images/url-monitor-retries.png
new file mode 100644
index 0000000..4a70ec7
Binary files /dev/null and b/images/url-monitor-retries.png differ
diff --git a/images/url-monitor-scheduling.png b/images/url-monitor-scheduling.png
new file mode 100644
index 0000000..42f5efe
Binary files /dev/null and b/images/url-monitor-scheduling.png differ
