diff --git a/website/assets/styles/pages/landing-pages/patch-faster.less b/website/assets/styles/pages/landing-pages/patch-faster.less index 1040d13669..6d983d2d1a 100644 --- a/website/assets/styles/pages/landing-pages/patch-faster.less +++ b/website/assets/styles/pages/landing-pages/patch-faster.less @@ -315,7 +315,7 @@ max-width: @max-content; margin: 0 auto; display: grid; - grid-template-columns: repeat(3, 1fr); + grid-template-columns: repeat(2, 1fr); gap: 40px; text-align: center; } diff --git a/website/views/pages/landing-pages/patch-faster.ejs b/website/views/pages/landing-pages/patch-faster.ejs index 02057142ce..82410603a7 100644 --- a/website/views/pages/landing-pages/patch-faster.ejs +++ b/website/views/pages/landing-pages/patch-faster.ejs @@ -5,8 +5,8 @@
Software management
-When a critical patch drops, the bottleneck isn't your team. It's your toolchain. Fleet's maintained app catalog and automated patch policies push updates to your devices on a regular, predictable cadence. No manual repackaging. No osquery queries to write. No waiting.
+When a critical patch drops, you're not always at your computer. Fleet's maintained app catalog and automated patch policies push updates to your devices on a regular, predictable cadence, even over the weekend, and without manual repackaging.
When a critical CVE drops, the clock starts. But for most IT and security teams, the bottleneck isn't awareness, it's the toolchain. Someone has to download the new version, validate it, package it, and get it into the catalog before a single device gets updated. If you're doing that manually, you're burning engineering time on work that doesn't have to be manual.
-The alternative is a catalog that's maintained for you, and policies that trigger automatically when a device falls behind. That's the difference between patching as a project and patching as a background process.
+When a critical CVE drops, the clock starts. But for most IT and security teams, the opportunity cost of packaging and automating every single app is really hard to justify, because there is other important work to do. Someone has to download the new version, validate it, package it, and get it into the catalog before a single device gets updated.
+The alternative is a catalog that's maintained for you, and policies that install software updates automatically, while still respecting the exceptions, flexibility, and user experience considerations you need to take into account to keep your end users productive.
Patch policies that run automatically
-A patch policy checks whether each Fleet maintained app is up to date on your hosts. Fleet auto-generates the correct osquery query for each app, so you don't write or update them. When a host fails the policy, Fleet automatically sends an install request.
+A patch policy checks whether each Fleet maintained app is up to date on your hosts. Fleet watches each app, so you don't write or update any code. When a host fails the policy, Fleet automatically sends an install request.
No osquery queries to write
Fleet auto-generates the correct query for each Fleet-maintained app.
-One-hour policy cadence
Policy checks run on a typical one-hour cadence on all online hosts.
@@ -147,7 +147,7 @@ <%/* ─── PLATFORM CALLOUT ───────────────────────────────── */%>Fleet manages software across macOS, Windows, and Linux from a single place. The same patch policies, the same catalog, the same automation, whether you're supporting a Mac-first team, a Windows shop, or a mixed environment with Linux servers.
+Fleet manages software across macOS, Windows, and Linux from a single place. The same patch policies, the same catalog, the same automation, whether you're supporting a Mac-first team, a Windows shop, or a mixed environment with Linux.
Use policy automations to trigger app updates, create tickets in Jira or Zendesk, or generate webhooks to connect Fleet to your existing workflows. Patching fits into the process you already have.