Add Download and Newsletter CTAs to articles

.vscode/settings.json

@@ -86,6 +86,8 @@
     "Fediverse",
     "FERPA",
     "Fevil",
+    "finalizers",
+    "finditer",
     "finnadie",
     "firko",
     "Flink",
@@ -110,6 +112,7 @@
     "gotk",
     "Grafonnet",
     "GSAP",
+    "gsutil",
     "hikari",
     "HMGET",
     "HMSET",
@@ -154,6 +157,7 @@
     "Kyverno",
     "labelledby",
     "LGPD",
+    "libc",
     "lighthousejs",
     "LIMS",
     "Linkify",
@@ -171,6 +175,7 @@
     "mathbb",
     "maxhdr",
     "Menlo",
+    "miscategorized",
     "misconfiguring",
     "mlflow",
     "Moodle",
@@ -218,6 +223,7 @@
     "Onest",
     "optin",
     "PABC",
+    "pacticipant",
     "PERC",
     "pgbouncer",
     "pgmq",
@@ -300,6 +306,7 @@
     "tftest",
     "TIMESTAMPTZ",
     "tktco",
+    "tlnp",
     "topk",
     "toset",
     "toxiproxy",
@@ -320,6 +327,7 @@
     "uncacheable",
     "uncordon",
     "Uncordoning",
+    "unexploitable",
     "unhold",
     "uninstrumented",
     "unsampled",

_TODO.md

@@ -127,13 +127,11 @@ https://mermaid.js.org/config/directives.html
 - /
 - /404
 - /about
-- /consent
 - /contact
 - /downloads/[slug]
 - /newsletter
 - /newsletter/confirm/[token]
 - /offline
-- /privacy/my-data
 - /search
 - /tags/[tag]
 - Bug reporter modal
@@ -259,3 +257,24 @@ This article has different approaches to [print pagination](https://www.customjs
 - Add links to the privacy policy page to go to preferences and my-data
 
 - The four service offerings should be clickable links that take you to the Contact page and pre-fill in the form with the service the person is interested in. The Contact project scopes could have the four services offerings and a "general questions" option.
+
+- Sticky the table of contents. It should scroll down to the bottom and then stay in place, and scroll up to the top when scrolling up. Should be pushed up the footer when it comes into the viewpoint on scroll down.
+
+- Color headings blue and use the SVG icon instead of the image. Color if the blue shade.
+
+- Social shares - module CSS doesn't appear correct with nested button hover classes, not sure how network name is generated or styled but it needs improvement. Should be rendered inside article content column, not across both content and TOC columns.
+
+
+ ### Component Stylings
+
+The bottom margin issues on CTAs need to handle paragraphs differently than headers. Headers are properly spaced now; paragraphs are flush with the CTA with no top margin.
+
+- Download CTA needs some styling tweaks. The checkmark on the two-column list component is too low on multi-line list items. It needs some bottom margin.
+
+- Newsletter CTA needs some bottom margin.
+
+- Callouts should get round corners like the Download and Newsletter CTAs
+
+- Tags need styled at the top of articles item view pages
+
+<Newsletter />

src/components/CallToAction/Download/index.astro

@@ -63,11 +63,12 @@ const downloadUrl = `/downloads/${normalizedResource}`
     <div class="lg:flex-1">
       <div class="flex items-center gap-2 mb-3">
         <span
-          class="inline-flex items-center gap-1 text-xs font-bold text-primary bg-primary/10 px-2.5 py-1 rounded-full"
+          class="inline-flex items-center gap-1 text-xs font-bold text-content bg-primary/10 px-2.5 py-1 rounded-full"
         >
           <Icon
             icon={"download-document"}
             size={3.5}
+            color={"content"}
           />
           Free PDF Guide
         </span>
@@ -98,7 +99,7 @@ const downloadUrl = `/downloads/${normalizedResource}`
             <Icon
               icon={"document"}
               size={8}
-              color={"text-primary"}
+              color={"secondary"}
             />
           </div>
           <p class="text-xs text-content-offset">Free resource · Instant access</p>
@@ -112,6 +113,7 @@ const downloadUrl = `/downloads/${normalizedResource}`
             <Icon
               icon={"download"}
               size={5}
+              color={"secondary"}
             />
             {buttonText}
           </a>

src/components/List/layouts/TwoColumnCheckIconsList.astro

@@ -26,7 +26,7 @@ const liClass = ["flex items-center gap-2", classes?.li]
       <li class:list={liClass}>
         <Icon
           icon="check-stylized"
-          color={"text-success"}
+          color={"success"}
           size={size ?? 5}
         />
         <span>

src/components/Social/Shares/index.astro

@@ -40,11 +40,11 @@ const iconBankId = `social-share-icon-bank-${Math.random().toString(36).slice(2)
 ---
 
 <div id={iconBankId} hidden aria-hidden="true">
-  <span data-social-share-icon="x"><Icon icon="x" size={24} color="inherit" /></span>
-  <span data-social-share-icon="linkedin"><Icon icon="linkedin" size={24} color="inherit" /></span>
-  <span data-social-share-icon="bluesky"><Icon icon="bluesky" size={24} color="inherit" /></span>
-  <span data-social-share-icon="reddit"><Icon icon="reddit" size={24} color="inherit" /></span>
-  <span data-social-share-icon="mastodon"><Icon icon="mastodon" size={24} color="inherit" /></span>
+  <span data-social-share-icon="x"><Icon icon="x" size={6} color="inherit" /></span>
+  <span data-social-share-icon="linkedin"><Icon icon="linkedin" size={6} color="inherit" /></span>
+  <span data-social-share-icon="bluesky"><Icon icon="bluesky" size={6} color="inherit" /></span>
+  <span data-social-share-icon="reddit"><Icon icon="reddit" size={6} color="inherit" /></span>
+  <span data-social-share-icon="mastodon"><Icon icon="mastodon" size={6} color="inherit" /></span>
 </div>
 
 <social-share-element

src/content/articles/alert-fatigue-reduction-triage-actionable-alerts/index.mdx

@@ -43,6 +43,8 @@ Export your alert definitions and firing history. Prometheus/Alertmanager stores
 
 For each alert, capture: alert name, firing frequency over the last 90 days, action rate (percentage of firings that required human intervention), owning team, and whether a runbook exists. The action rate column is the most important and the hardest to populate—you'll need to cross-reference alert firings with incident tickets or on-call logs.
 
+<Newsletter />
+
 ### Step 2: Classify by Action Rate
 
 Once you have the inventory, sort by action rate. This single metric tells you more about alert usefulness than anything else.
@@ -94,14 +96,30 @@ Establish a cadence: monthly reviews of which alerts fired most and what their a
 
 Counter the growth with a deletion budget: every quarter, each team must delete or significantly improve 10% of their alerts. It's aggressive enough to force real decisions, but sustainable enough that teams don't feel like they're dismantling their monitoring.
 
+<Download
+  resource="alert-fatigue-reduction-triage-actionable-alerts"
+  title="Download the Alert Fatigue Reduction Guide"
+  description="Get the complete framework for auditing noisy alerts, improving action rates and building a sustainable on-call system with fewer, higher-signal pages."
+  listItems={[
+    {
+      text: "Alert inventory worksheet templates",
+    },
+    {
+      text: "Action-rate classification decision matrix",
+    },
+    {
+      text: "Noise reduction tuning patterns",
+    },
+    {
+      text: "Quarterly alert cleanup cadence",
+    },
+  ]}
+/>
+
 ## The Results
 
 Remember the system I inherited? Forty-seven alerts per day, forty-four requiring no action—a 6% action rate. MTTA had drifted to 12 minutes. On-call satisfaction was 4/10.
 
 After six months of systematic auditing, classification, and deletion: 5 meaningful pages per day, 90% action rate, 3-minute MTTA, on-call satisfaction at 8/10. That's an 80% reduction in volume with fifteen times the signal quality.
 
 The alerts that remain are genuinely important. When something pages, it means something. Engineers trust the system again.
-
----
-
-Want the complete framework? Download our [Alert Fatigue Reduction Guide](/) for detailed coverage of SLO-based alerting, multi-window burn rate thresholds, runbook templates, alert testing checklists, and maintenance schedules.

src/content/articles/api-deprecation-sunset-headers-consumer-migration/index.mdx

@@ -63,6 +63,8 @@ Table: Key deprecation metrics with alert thresholds.
 
 One critical point: the moment you announce a deprecation, stop allowing new consumers to adopt the deprecated API. Every new adoption extends your deprecation timeline and increases your support burden. Block new API keys from accessing deprecated versions. Remove deprecated APIs from public documentation. Stop distributing SDK versions that use the deprecated API.
 
+<Newsletter />
+
 ## Graduated Enforcement: The Secret Weapon
 
 This is where most deprecation strategies fail. They announce, they communicate, they provide migration guides—and then they do nothing when consumers ignore all of it. The sunset date arrives, someone important is still using the deprecated API, and the date gets pushed back. Repeat indefinitely.
@@ -118,6 +120,26 @@ The escalation timeline ties communication to enforcement:
 
 Document every escalation attempt. When a consumer claims they were not warned, you need a record showing the emails sent, the calls attempted, and the responses (or lack thereof). This documentation protects you organizationally and sometimes legally.
 
+<Download
+  resource="api-deprecation-sunset-headers-consumer-migration"
+  title="Download the API Deprecation Playbook"
+  description="Get the complete deprecation framework with Sunset header patterns, enforcement timelines, and consumer migration workflows you can apply immediately."
+  listItems={[
+    {
+      text: "Sunset header implementation patterns",
+    },
+    {
+      text: "Consumer migration tracking queries",
+    },
+    {
+      text: "Graduated enforcement timeline playbook",
+    },
+    {
+      text: "Enterprise escalation communication checklist",
+    },
+  ]}
+/>
+
 ## It Actually Works
 
 Remember those three enterprise customers who had not migrated after two years? We eventually got all of them to zero traffic on the deprecated API.
@@ -134,13 +156,3 @@ The principles are straightforward:
 - _Plan for resistance_. Some consumers will not migrate until it hurts. Build your escalation path assuming this, and you will be pleasantly surprised when consumers migrate early.
 
 Deprecation is not a single announcement—it is a sustained campaign that requires attention for months. Staff it accordingly.
-
----
-
-## Want the Complete Playbook?
-
-This article covers the core strategies, but there is much more to successful API deprecation: Sunset header implementation details (RFC 8594), consumer tracking queries, migration guide templates, SDK deprecation patterns, handling contractual obligations, versioning strategies to reduce future pain, and a complete quick-reference checklist.
-
-Download the full _API Deprecation Playbook_ PDF for the complete deep-dive, including code examples and implementation templates you can adapt for your own deprecations.
-
-[Download the API Deprecation Playbook (PDF)](/)

src/content/articles/api-gateway-metrics-traces-logs-debugging/index.mdx

@@ -214,6 +214,8 @@ Code: Tail sampling configuration to keep all errors and slow requests.
 
 This captures the traces you actually need for debugging—failures and performance problems—without storing millions of routine successful requests.
 
+<Newsletter />
+
 ## A Quick Debugging Workflow
 
 When latency alerts fire, follow this pattern: metrics narrow scope → traces show detail → logs explain why.
@@ -276,6 +278,26 @@ Search logs for the affected time range and route. Look for:
 
 The pattern is always the same: start broad with metrics, zoom in with traces, explain with logs.
 
+<Download
+  resource="api-gateway-metrics-traces-logs-debugging"
+  title="Download the API Gateway Observability Guide"
+  description="Get the complete framework for gateway metrics, trace propagation, and debugging workflows that isolate production latency failures quickly."
+  listItems={[
+    {
+      text: "Gateway RED metrics playbook",
+    },
+    {
+      text: "Latency decomposition instrumentation patterns",
+    },
+    {
+      text: "Correlation logging implementation guide",
+    },
+    {
+      text: "Incident debugging workflow templates",
+    },
+  ]}
+/>
+
 ## Conclusion
 
 Gateway observability isn't about collecting more data—it's about making the gateway transparent so you can answer three questions in seconds instead of hours:
@@ -287,18 +309,3 @@ Gateway observability isn't about collecting more data—it's about making the g
 The comprehensive guide (linked below) covers additional topics: structured logging with correlation IDs, dashboard design for debugging instead of monitoring, alerting strategies to reduce noise, handling high-cardinality consumers, and controlling costs in production.
 
 _Start with latency breakdown metrics. Add distributed tracing once you need request-level visibility. Everything else is details. The difference between a 5-minute fix and a 5-hour nightmare is knowing which side of the gateway is slow._
-
----
-
-## Want the Complete Guide?
-
-This article covered the fundamentals of gateway latency visibility and distributed tracing. The complete deep-dive guide includes:
-
-- **Complete metric instrumentation**: RED method metrics, consumer-level metrics, upstream health tracking
-- **Structured logging with correlation IDs**: Request ID propagation, error context logging, log aggregation strategies
-- **Dashboard design for debugging**: Overview dashboards, drill-down workflows, consumer-specific views
-- **Alert strategies**: SLI-based alerts, upstream-specific alerts, consumer abuse detection
-- **Three complete debugging scenarios**: Latency spikes, intermittent 503 errors, consumer-specific performance issues
-- **Implementation considerations**: Cardinality management, performance impact, cost considerations, security and privacy, testing your observability, vendor-agnostic instrumentation with OpenTelemetry
-
-**[Download the complete guide (PDF)](/)**—over 8,800 words of in-depth coverage with code examples, diagrams, and real-world debugging workflows.

src/content/articles/api-usage-metering-quotas-cost-attribution/index.mdx

@@ -133,6 +133,8 @@ Code: Idempotent insertion using unique constraint on event_id.
 
 Pick idempotency keys if you're using PostgreSQL or TimescaleDB—they support unique constraints natively and give you exact deduplication. Use time-window deduplication if you're on ClickHouse or Prometheus where unique constraints aren't available. The storage cost of keeping event IDs is negligible compared to the cost of billing disputes.
 
+<Newsletter />
+
 ## Enforcing Quotas Before Costs Explode
 
 ### Rate Limits vs Quotas
@@ -227,6 +229,26 @@ When the billing period ends and quotas reset to zero, requests immediately succ
 
 Implement this in your application logic: if a request is denied due to quota but the timestamp is within 5 minutes of the period boundary, check if the next period has started. If so, allow the request and count it against the new period. This prevents frustrating "429 errors at midnight" support tickets.
 
+<Download
+  resource="api-usage-metering-quotas-cost-attribution"
+  title="Download the API Cost Management Guide"
+  description="Get the complete implementation guide for API metering, quota controls, and chargeback models that improve cost accountability."
+  listItems={[
+    {
+      text: "Metering architecture design patterns",
+    },
+    {
+      text: "Quota enforcement implementation strategies",
+    },
+    {
+      text: "Chargeback model decision framework",
+    },
+    {
+      text: "Pricing and reconciliation workflows",
+    },
+  ]}
+/>
+
 ## Getting Started: Your First 30 Days
 
 You don't need to implement everything at once. Here's the path that works:
@@ -246,9 +268,3 @@ Start small: one API, request count only, read-only dashboard. Learn from 30 day
 </Callout>
 
 The mistake I've seen repeatedly: teams try to implement metering, quotas, cost attribution, billing integration, and organizational rollout simultaneously. It's too much. Build the metering foundation first. Everything else becomes easier once you have usage data.
-
----
-
-**Want the complete implementation guide?** This article covers the foundation—metering and quotas. The full deep-dive includes cost attribution models, billing platform integration (Stripe, AWS Marketplace), organizational rollout strategies, pricing model evolution, dispute handling, and a complete implementation checklist with 20+ code examples.
-
-Download the complete guide: API Cost Management: Metering, Quotas, and Chargebacks

src/content/articles/argocd-sync-failures-gitops-debugging-troubleshooting/index.mdx

@@ -117,6 +117,8 @@ The output tells you sync status (Synced, OutOfSync, Unknown) and health status
 
 The `--show-operation` flag shows which phase the sync is in. "Running PreSync hooks" means a hook is stuck. "Sync error" with a message means apply failed.
 
+<Newsletter />
+
 ### Step 2: Examine ArgoCD Logs
 
 ArgoCD has several components, each handling different parts:
@@ -191,14 +193,28 @@ If a resource shows OutOfSync but the diff looks identical, check for whitespace
 
 ArgoCD sync failures are frustrating because they break the promise of GitOps: you pushed to Git, so it should just work. But that frustration fades once you understand what's happening beneath the abstraction.
 
+<Download
+  resource="argocd-sync-failures-gitops-debugging-troubleshooting"
+  title="Download the ArgoCD Troubleshooting Guide"
+  description="Get the complete GitOps debugging reference for sync waves, hook failures, and recovery workflows during blocked deployments."
+  listItems={[
+    {
+      text: "Sync wave ordering runbooks",
+    },
+    {
+      text: "Hook deadlock diagnosis checklist",
+    },
+    {
+      text: "OutOfSync loop remediation patterns",
+    },
+    {
+      text: "Production recovery workflow guide",
+    },
+  ]}
+/>
+
 The workflow covered here gives you a systematic approach: identify _what_ failed by checking ArgoCD status, understand _when_ it failed by examining sync waves and hooks, verify _why_ it failed by inspecting Kubernetes state, and test your fix before committing. Most failures fall into a few recognizable categories—once you identify the pattern, the fix is usually straightforward.
 
 What makes this workflow valuable isn't memorizing every edge case. It's building a mental model of what ArgoCD is actually doing during sync. When you understand that sync waves control ordering, that hooks block until completion, and that health checks determine when ArgoCD considers a resource "ready," you can reason about failures even when they don't match a known pattern.
 
 GitOps isn't magic—it's automation. When the automation fails, you need to understand what it was trying to do. The declarative model abstracts away the _how_ of deployment, which is powerful until something goes wrong. Then the abstraction becomes the obstacle. The debugging skills in this article help you see through it.
-
----
-
-**CTA Title:** Go Deeper: The Complete ArgoCD Troubleshooting Guide
-
-**CTA Body:** This article covers the essential debugging workflow, but production incidents often require more. The complete guide includes detailed runbooks for specific failure scenarios (stuck hooks, CRD ordering, pruning accidents), prevention strategies (CI validation, sync windows, alerting configuration), and advanced recovery techniques for when ArgoCD state becomes corrupted. Download the PDF to have a comprehensive reference ready for your next sync failure.