Skip to main content

Best Practices and Tips

Practical recommendations for getting the most out of Level once your initial setup is in place.

Updated today

Introduction

Once devices are enrolled, tags are set up, and your default automations and monitors are running, you're operational. This article covers what to do next β€” common patterns that make Level work better as your environment grows.


Get Tagging Right First

Everything in Level targets devices by tag. Monitors, automations, update schedules β€” they all use tags to determine which devices they apply to. If your tags are inconsistent, you'll spend a lot of time troubleshooting why something ran on the wrong device or didn't run at all.

A few principles that hold up well in practice:

  • Tag what a device is, not who owns it. "Windows," "Workstation," "Production" scales. "John's Laptop" doesn't.

  • Avoid synonyms. "Mac" and "macOS" mean the same thing but won't match the same automations. Pick one and document it.

  • Let automations apply tags. The Default Tags automation handles device-type tags automatically. For anything more specific, build an automation rather than tagging manually β€” consistency improves at scale.


Use the Get Started Automations as Templates

The pre-built automations in the Get Started group aren't just useful out of the box β€” they're also good examples of how to structure your own. Before building something from scratch, open the closest equivalent in Get Started, duplicate it, and modify the copy.

Useful automations to build early:

  • New device onboarding sequence. Trigger: New Device Detected (or Tag Applied for a setup tag). Actions: apply baseline tags, install standard software via winget, run a configuration script, restart. This is how you enforce a consistent baseline without touching each device manually.

  • Reboot with user approval. The "Prompt User to Restart" automation in Get Started is a good starting point. It lets you initiate a reboot on an uptime threshold or after updates, but presents the end user with a prompt first so they can save work. Better than forcing a cold restart.

  • Weekly maintenance run. Trigger: Weekly schedule. Actions: install updates, run Disk Cleanup, check for long uptime and prompt restart if needed. One automation handles routine maintenance across all devices.

πŸ’‘ TIP: Build automations that target specific tags rather than specific devices. When you add a new device and tag it correctly, it automatically inherits every automation that targets that tag β€” no additional configuration needed.


Layer Your Monitor Policies

The Monitoring - Global policy that comes with your account covers the fundamentals. As you get more specific, add focused policies on top:

  • A security policy for event log monitors watching for failed logins, privilege escalation attempts, AV/EDR monitoring, or unauthorized software.

  • Service-specific policies that checks whether critical services (Nginx, SQL Server, a custom application) is running β€” and can restart it if it stops.

  • An uptime policy targeting servers specifically, with tighter thresholds than workstations.

Each additional policy targets a narrower tag set. A "Server" policy only runs on devices tagged "Server." A "Nginx" policy only runs on devices tagged "Nginx." You build coverage by stacking policies, not by cramming everything into one.

ℹ️ NOTE: You can see all monitors applied to a specific device in the Monitors tab of the device detail view. Use this to verify coverage and catch gaps.


Think Twice Before Manual Tagging

Manual tagging is fine for one-offs. For anything you're doing repeatedly, build an automation. A few examples of where automations beat manual work:

  • OS tagging. Setup your Default Tags automation to handle this. Enable it and stop thinking about it.

  • Role tagging based on hostname or installed software. Use a script action that checks for a characteristic (hostname prefix, installed service, registry key) and applies a tag based on the result.

The pattern is: if you're tagging more than a handful of devices the same way, there's probably an automation that can do it for you.


Use Maintenance Mode During Changes

When you're doing planned work on a device β€” software installs, configuration changes, migrations β€” put it in Maintenance Mode first. Maintenance Mode suppresses monitor alerts and alert-triggered automations so you don't get flooded with false alarms or trigger unintended remediation during the work.

Navigate to the device detail view, open the Maintenance Mode section, and set a duration. The device comes back to full monitoring automatically when the duration expires.

⚠️ WARNING: Maintenance Mode suppresses monitor-triggered alerts only. Scheduled automations and manually triggered automations continue to run.


Script the One-Off Stuff

Level's Scripts library is for more than automation. When you need to check something on a single device β€” verify a registry key, look up installed software, pull system info β€” write the script once, save it to the library, and run it on-demand from any device without SSH or RDP.

Scripts in the library are available from any device (under Actions) and can be run directly or referenced inside automations. Write it once, use it anywhere.


Check History Regularly Early On

The History view logs every automation run and script execution. When you're first enabling automations, check History after each run to confirm actions completed as expected. Automation runs that fail silently are the most common source of early confusion.

Once you've validated that automations are running correctly, you don't need to check History constantly β€” but it's the right place to go when something doesn't behave as expected.


FAQ

  • What's the fastest way to get a consistent configuration on every new device? Build a new device onboarding automation triggered by a Tag Applied event (the setup tag you apply to new enrollments). Chain all your standard configuration steps as actions β€” software installs, settings, additional tagging β€” and every new device gets the same baseline automatically.

  • Should I use groups or tags for targeting? Tags for automations and monitors. Groups for permissions, group-level defaults, and organizational structure. They're complementary β€” you'll use both, but tags drive most of the targeting logic.

  • Can I run an automation against a device right now without waiting for the trigger? Yes. From the device detail view or from the Automations page, you can trigger an automation manually. This is useful for testing before you enable a scheduled or event-based trigger.

  • How do I know if an automation ran successfully? Check History. Each automation run has a status (success or failure) and a log you can expand to see what happened at each step.

  • How do I handle devices that need exceptions to a standard policy? Use a more specific tag. If most Windows devices get one set of monitors but a group of servers needs different thresholds, tag those servers with "Exchange" or "DC" and build a policy that targets that tag. More specific tags let you override or supplement the baseline without touching every device manually.

Did this answer your question?