> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Sites and Devices

> Create, review, update, and retire SDX sites while understanding how heartbeats and asynchronous jobs affect site state.

A site is the operational record for a managed MikroTik router. SDX stores the site record, enriches it with metadata, and uses it as the target for policies, jobs, backups, scripts, workflows, metrics, and reports.

## Prerequisites

Before you manage sites, make sure you have:

* Permission to view or manage sites.
* A clear naming and tagging standard for your organization.
* Router access if you are onboarding a physical device.
* A control plane policy ready for new sites.

## Create a Site

<Steps>
  <Step title="Open Sites">
    In the SDX portal, go to **Sites**.
  </Step>

  <Step title="Add the site">
    Select **Add**, enter a site name, and save the record.
  </Step>

  <Step title="Onboard the router">
    Open the new site, generate the bootstrap command, run it on the MikroTik router, and wait for the first heartbeat.
  </Step>

  <Step title="Add context">
    Add tags, notes, and any required metadata after the site appears online.
  </Step>
</Steps>

## Understand Site Status

<CardGroup cols={2}>
  <Card title="Online" icon="circle-check">
    The router is checking in and SDX has recent heartbeat data. Live commands and remote access are more likely to succeed.
  </Card>

  <Card title="Offline" icon="circle-x">
    SDX has not received expected heartbeats. Queued jobs can still be accepted by SDX, but the router cannot pick them up until it reconnects.
  </Card>

  <Card title="Last Seen" icon="clock">
    The most recent timestamp SDX has for the site. Use this with fault history when you investigate intermittent links.
  </Card>

  <Card title="Tunnel State" icon="shield">
    The management tunnel state. Live commands and transient access depend on the active management path for the site.
  </Card>
</CardGroup>

## Review a Site

Open a site to inspect:

* Overview and status
* Device identity and RouterOS details
* Metrics and live dashboard data
* Fault event log
* Inventory and discovered devices
* Remote access tools
* Configuration backups
* WAN failover settings
* API credentials and management settings
* Notes, metadata, and tags

<Note>
  Some views use stored data and remain useful while a site is offline. Live views require the management path to be available.
</Note>

## Edit Site Details

Use the site settings or overview actions to update the site name, notes, tags, metadata, or operational settings. Keep names human-readable because they appear in dashboards, reports, notifications, workflow context, and search.

Changing metadata is usually immediate in the portal. Applying a device-level change, such as a policy update or job, may be asynchronous.

## Delete a Site

Only delete a site when you are sure the router should no longer be managed by SDX.

<Warning>
  Deleting a site removes the operating record used by downstream features. If you are troubleshooting an offline router, keep the site and use the troubleshooting checklist instead.
</Warning>

Before deletion:

* Export or review any backups you need to retain.
* Check whether workflows, reports, policies, or notification rules depend on the site.
* Confirm the site is not part of a managed VPN, captive portal, WAN failover, or security rollout.
* Record the reason in your internal change or ticketing system.

## Best Practices

<CardGroup cols={2}>
  <Card title="Name for Operations" icon="text-cursor-input">
    Use names that make sense in an alert at 2 a.m. Avoid internal abbreviations that only one person understands.
  </Card>

  <Card title="Tag Before Scaling" icon="tags">
    Create consistent tag keys before you onboard many sites. Retrofitting tags after reports and workflows exist is slower.
  </Card>

  <Card title="Back Up Before Changes" icon="archive">
    Request a fresh backup before policy, script, WAN, or security changes.
  </Card>

  <Card title="Use Fault History" icon="triangle-alert">
    Do not rely only on the current status badge. Review recent faults and heartbeat history for intermittent issues.
  </Card>
</CardGroup>