Feature Requests

Every event Anvil captures gets richer context: how much memory the driver used before and after, how much CPU time the handler consumed, which controller model and OS version it's running on, and how long the controller has been up. This runs for every event with essentially zero overhead. It's not something you turn on for a debugging session — it's always there. Two concrete outcomes. First, memory leaks become visible: the event timeline picks up a slow, steady climb in memory that wouldn't otherwise be obvious, and flags the individual events allocating disproportionately. Second, when something is slow, you can tell what kind of slow it is — an event that spent 500ms inside your code is a different problem from an event that spent 500ms waiting on a network call. Over time, the same data supports cross-cuts like "this driver behaves differently on an EA-1 vs an CORE 5" or "memory usage jumped after the Director 4.1 update". What we're thinking: Memory usage and CPU time on every event — automatic, no configuration Memory-over-time chart with leak detection Flags on events that allocate much more than the rolling average Controller model, OS version, uptime, and reboot markers visible alongside the event Ability to compare a driver's behaviour across different controller models Help us shape this: How do you diagnose memory or performance problems in your drivers today? Is automated leak detection more useful than manual inspection, or vice versa? How valuable is comparing a driver's behaviour across different controller models or OS versions?

When an event is slow, know where the time went — not just that the overall handler took 500ms, but which function inside it was responsible, and which functions that function called. Most driver events are a tree of function calls: an event handler calls a few helpers, those call C4 API methods, some branches are fast, others aren't. Without profiling, that tree is invisible — all you see is a single duration for the outer handler. Method-level profiling captures the full call tree for an individual event. You can view it as a flame graph (the hot paths stand out visually), as a waterfall chart (good for understanding when in the event each call happened), or as a collapsible call tree (good for reading the code path, especially when exploring unfamiliar code). Because capturing that much detail has overhead, profiling is opt-in. You turn it on when investigating a specific problem or when you want to understand an event's shape, and turn it off when you're done. What we're thinking: Toggle profiling on for the next N events, or for a whole session Flame graph, waterfall, and call tree views of a single event Filter to profile only specific event types (e.g. only ExecuteCommand) C4 API calls included in the tree so you can see where API time is spent Help us shape this: When you hit a slow event today, what do you do to figure out why? Which view would you reach for first — flame graph, waterfall, or call tree? Would on-demand profiling be enough, or would a lightweight always-on mode (top-level calls only) be more useful?

Most observability tools treat environments as something you tag explicitly — local, staging, QA, production. Control4 driver development has a simpler shape: you test on your own controller while building, then the driver goes out to dealers and end-users and stops being something you directly control. Environments in Anvil would reflect that reality with two implicit modes — Development and Production — rather than asking you to label every telemetry payload yourself. Development is everything you already see: full event, log, and error detail from your own controller while you're iterating. Production is the opt-in side, populated only when you enable production monitoring for a release and data starts flowing back from dealer installs. The two streams share the same project but stay clearly separated: a noisy error you intentionally triggered while debugging doesn't show up in your production error counts, and a spike in the field doesn't get buried under your own test traffic. Where development and production data coexist, an environment filter sits at the top of each data view and you can switch between "All", "Development", and "Production" as needed. Production data is visually distinct — a different badge colour, clear labelling in detail views — so you never have to guess which side of the fence you're looking at. For projects that never enable production monitoring, the filter stays hidden and nothing changes from today. Custom environment names beyond development and production are deliberately out of scope for now; most driver workflows don't have intermediate stages that need their own bucket, and we'd rather keep the mental model simple until we hear otherwise. What we're thinking: Two implicit environments: Development (default) and Production (opt-in via production monitoring) Environment filter on data views when production data is present Visual distinction (badge colour, labelling) so the two are easy to tell apart Separate aggregations — dev errors don't pollute prod metrics and vice versa Stricter privacy controls on production data (anonymised install IDs, no PII) Different retention windows if needed (longer for production, for compliance) Custom environment names deferred — intentionally not in v1 Help us shape this: Does your workflow have anything that looks like a staging step — a QA controller, a beta dealer, a test installation — or is it really just "your machine" then "production"? Would you ever need to look at dev and prod data side-by-side in the same view, or are they different enough that you'd always filter to one? If we later added custom environment names, what would you use them for?

The third-party integrations Anvil ships out of the box won't cover everything — internal dashboards, custom issue trackers, data warehouses, CI/CD pipelines, or homegrown alerting tools. Webhooks would give you a generic way to have Anvil notify any HTTPS endpoint when something happens, so you can wire it into the tools your team already runs without waiting for a first-class integration. You'd configure a webhook by giving it a name, a URL, and a list of events to subscribe to — new errors, regressions, resolved errors, error spikes, new releases, published releases. When one of those events fires, Anvil POSTs a JSON payload with consistent structure (organization, project, event type, and event-specific data) and an optional HMAC signature so your receiver can verify the request really came from Anvil. You can add custom headers for authentication, set a shared secret, and test the webhook against your endpoint before saving. Because webhooks can fail for reasons outside Anvil's control, failed deliveries retry with exponential backoff and a delivery log shows recent requests, their status codes, response times, and retry history. If a webhook fails repeatedly it's auto-disabled and admins are notified, so broken integrations don't quietly stop working. The feature is aimed at teams with custom tooling — Anvil's own built-in integrations (Jira, Linear, Slack, etc.) cover the common cases, and webhooks are the escape hatch for everything else. What we're thinking: HTTPS-only webhook endpoints configured per project Subscribable events: new errors, regressions, resolved errors, error spikes, new releases, published releases Consistent JSON payload shape with organisation, project, and event-type data Optional shared-secret HMAC signing so receivers can verify authenticity Custom headers (for auth tokens or routing) Test-webhook button during configuration Retry with exponential backoff on failure, auto-disable after repeated failures Delivery log showing recent requests, response codes, and retry state Help us shape this: What would you connect a webhook to first — a chat channel, an internal ticket system, a data warehouse, something else? Are there events beyond errors and releases that you'd want to subscribe to (comments, assignments, configuration changes)? Would per-environment webhooks matter to you — for example, different endpoints for staging vs. production?

A stack trace tells you where an error happened, not how your driver got there. For bugs that depend on sequence or timing — a callback that runs in the wrong order, a proxy command that arrives before the driver is ready, a property that was set to something unexpected just before the failure — the trail of events leading up to the error is usually the thing you most want to see. Anvil would automatically capture a rolling trail of recent activity for every driver instance: C4:* API calls, callback entries, property changes, timers, proxy messages, and outbound network requests, each with a timestamp and the relevant arguments. When your driver throws an error, or you call the Anvil SDK to capture one, the most recent slice of that trail goes along with the report. The stack trace shows the point of failure; the breadcrumb trail shows the run-up. You can also add breadcrumbs of your own wherever something significant happens in your driver — a user action, a state transition, a branch in business logic — so the trail reflects meaningful moments rather than just raw API calls. The trail lives in memory on the controller and is only transmitted when it's attached to an error, so there's no steady stream of data leaving the device in the background. In the UI, breadcrumbs for an error can be filtered, searched, and expanded to show the full arguments for a specific call. What we're thinking: Automatic capture: C4 API calls, callback entries, property changes, timers, network requests, proxy messages A simple SDK call to add your own breadcrumbs with a category, message, level, and arbitrary data Configurable buffer size (default around 100 events) Trail transmitted only when attached to an error — no ambient bandwidth cost Timeline view in the UI with filtering by type and free-text search Automatic redaction of sensitive patterns (tokens, credentials) before transmission Option to disable specific automatic capture types if they're noisy for your driver Help us shape this: Which kinds of automatic breadcrumbs would be most useful to you — C4 API calls, proxy messages, property changes, something else? Would you prefer a longer trail (more history, bigger error payloads) or a shorter one (lighter, less context)? When you've debugged a tricky sequencing bug in the past, what did you wish you could see at the moment of failure?

Every driver you ship is a new release, and when something starts going wrong the first thing you usually want to know is which version is doing it. Anvil already captures the driver version on errors and shows which versions are affected for each error group. Release tracking would extend that coverage to events and logs, and layer a proper notion of a release on top — with release notes, status, adoption metrics, and side-by-side comparison. The Releases page would list every version of a driver with the errors, events, and a quick sense of how each release is performing in the field. When you look at a single release, you'd see the errors that first appeared in that version, a summary of event volume, and an adoption curve showing how many controllers are running it over time. Error detail pages would pick up "Introduced in v1.2.3" and "Fixed in v1.2.4" context so you can tell at a glance which deployment caused or resolved an issue. Releases can be created manually — with notes you write when you cut a version — or drafted automatically when Anvil sees a previously-unknown version appear in telemetry. Comparison between two releases surfaces the differences that matter: errors present in the new release but not the old one, errors the new release resolved, and shifts in error rate or event volume between the two. Coupled with the existing source-map upload flow, this turns version tags into a first-class dimension you can filter, compare, and correlate against. What we're thinking: Driver version captured on events and logs, not just errors (consistent across all three data types) A Releases page per project with version list, status (draft/published/deprecated), and release notes "Introduced in" and "Fixed in" version context on every error Release comparison: new vs resolved errors between two versions Adoption curve showing how many controllers are running each version over time Automatic draft-release creation when a new version first appears in telemetry CLI commands for creating and publishing releases alongside source-map upload Help us shape this: How do you version your drivers today — semver, date-based, build numbers, something else? What format would you want Anvil to display? Is "introduced in version X" context something you'd want computed automatically, or do you prefer to associate errors with releases yourself? Which would be more valuable earlier: release notes and changelog storage, or release-vs-release error comparison?

For teams that manage driver development through a corporate identity provider, Anvil would support signing in with SAML 2.0 or OIDC. Members of an organization would authenticate with their company credentials — Okta, Azure AD, Google Workspace, OneLogin, or any other SAML/OIDC-capable provider — rather than with a separate Anvil password. Existing Anvil identities link to the corporate directory, so your team doesn't maintain two sets of logins. When SSO is required for an organization, joining and leaving follow the normal employee lifecycle. A new hire added to your IdP's Anvil group gets access to the org the first time they sign in. Someone who leaves loses access at the same moment their company account is deactivated, with no separate step to remove them from Anvil. Contractors, consultants, and anyone else who comes and goes is handled by whatever rules already govern access to your other tools. SSO can be set to optional (members can sign in either way) or required (SSO is the only path into the org). Session duration is configurable per organization so policies around re-authentication match the rest of your internal tooling. Users who belong to more than one org — for example, an employee of one Anvil customer who also helps out a partner — keep a single Anvil identity and pass through the right SSO check when they switch between them. What we're thinking: SAML 2.0 and OIDC support Per-organization configuration by an admin, with a test-configuration step before going live Optional or required SSO enforcement Configurable SSO session duration Just-in-time provisioning so new employees don't need to be pre-invited Attribute mapping (name, email, optionally group → role) Audit logging of SSO sign-ins and config changes Help us shape this: Which IdP does your team use, and do you already rely on it for other developer tools? Do you need SSO to be required for your org, or is optional SSO enough? Would you want group-based role assignment (e.g. an "Anvil Admins" group in your IdP mapping to admin access) from day one, or is that a later refinement?

For teams that share responsibility for a driver, every error you see is also something that someone might already be on top of — or might have slipped through the cracks. Anvil would add the things you need to turn a list of errors into a shared backlog: a status for each error, an assignee, a thread of comments, and notifications when something you care about changes. Errors progress through a small set of statuses — New, Ongoing, Resolved, Regressed — so at a glance you can tell what's been looked at and what hasn't. When an error is marked Resolved and then happens again, it's flagged as Regressed, so you find out a fix didn't hold without needing to remember what you shipped last week. Errors can be muted for a chosen period when you know something is noisy and don't want to be pestered until you've landed the fix. Assignment and comments give the team a place to discuss the error next to the error itself, rather than in a separate chat channel or ticket. Assign an error to a teammate, @mention someone to pull them in, leave notes for whoever picks it up next. Watchers get notified when things change — a comment, a status flip, a regression — so the right people hear about it without everyone subscribing to everything. What we're thinking: Error statuses: New, Ongoing, Resolved, Regressed Automatic regression detection when a Resolved error recurs Muting for a fixed period (1 hour, 4 hours, 1 day, 7 days) Assignment to a single teammate per error Markdown comments with @mentions Watch an error to receive notifications on activity Email notifications at launch, in-app notification center next, chat integrations later Bulk actions for resolving or assigning many errors at once Help us shape this: Where does error triage live for your team today — chat channels, tickets, a spreadsheet, nothing formal? What's more useful earlier: assignment and a single clear owner, or comments and group discussion? Which notification channel matters most to you — email, in-app, or a Slack/Teams integration?

Today Anvil is focused on the development loop: you see your own driver running on your own controller with full detail. Production monitoring would extend Anvil to cover the other side of the driver lifecycle — once your driver is in customers' homes, running on dealers' controllers, with no direct visibility on your end. The goal is to let you find out about a regression because Anvil surfaces it, not because a dealer calls you. In production mode the shape of the data changes. Instead of every event with full payload in real time, you get aggregated views: crash-free rates, version distribution, top errors with occurrence and install counts, error timelines. Errors are grouped by fingerprint across thousands of installs, so one underlying bug shows up as one entry rather than thousands. Logs are sampled instead of streamed in full, with the option to capture full logs for a specific install if you're helping a dealer chase something down. A Releases view shows how each version of your driver is performing in the field, including rollout progress as newer versions replace older ones. Because production data comes from controllers in customer homes, the model is privacy-first by design. Install IDs are hashed and not traceable to specific customers, controller IDs and customer information aren't collected at all, and dealers can disable telemetry per install if their customer requires it. A Development/Production toggle at the top of the project makes the mode you're in obvious, and the two modes have different navigation so the aggregate-focused production UI doesn't clutter your day-to-day debugging work. What we're thinking: Development/Production mode toggle per project, with clear visual distinction Production overview dashboard: active installs, error rate, crash-free rate, version distribution, top errors Aggregated error view with fingerprint grouping across thousands of installs Sampled production logs with configurable sampling rate (1%, 10%, 100%) and per-install full capture Release tracking: rollout progress, error rate per version, crash-free rate per version Privacy-first telemetry: hashed install IDs, no PII, per-install opt-out Alerting on error spikes, new errors in a release, regressions Help us shape this: How do you find out about problems in your driver today once it's deployed — dealer reports, customer complaints, nothing until something breaks badly? What would be more useful earlier: aggregated error reports from all installs, or a way to pull detailed data from a specific install when a dealer contacts you? What's your comfort level with telemetry from customer controllers — do dealers or end customers push back on it, and what would they need to see to be comfortable with it?

Driver code often handles credentials, tokens, customer identifiers, or other things that shouldn't end up in centralised logging — and most of the time they don't, until somebody accidentally prints one. Data protection would add a set of safeguards that catch that sort of accident before it becomes a problem, and give teams with stricter compliance requirements the controls they need to use Anvil confidently. At the centre is auto-redaction: common sensitive patterns (API keys, JWTs, credit card numbers, private keys, passwords in URLs, and more) are detected and masked at ingestion, before the data is stored. Because redaction happens up front, the original value is never persisted and there's no way to recover it — which is the point. Alongside redaction, secrets detection alerts your team when something that looked sensitive was intercepted, so you can fix the code path that sent it rather than relying on the safeguard to keep catching it. Other controls give you coarser-grained protection. An IP allowlist lets you restrict ingestion to known controller or network ranges so unexpected sources can't send data to your project. An audit log records significant organisation actions — logins, member changes, API key creation, integration connections, security setting changes — so you can answer "who did what, and when" after the fact. Enterprise-tier additions include custom redaction patterns, session management, enforced MFA, data export controls, data residency options, and the GDPR/SOC 2 tooling that larger customers need. What we're thinking: Auto-redaction of common sensitive patterns (API keys, JWTs, credit cards, SSNs, private keys, passwords in URLs) at ingestion Secrets detection with alerting when sensitive data is intercepted — via email, Slack, Teams, or an issue tracker IP allowlist for project ingestion (individual IPs or CIDR ranges) Per-API-key IP allowlist for fleet deployments where each key has a known controller Audit log of significant organisation actions with filtering and CSV export Custom redaction patterns for organisation-specific identifiers (Enterprise) Org-wide API key rotation policy (Enterprise) — enforce a maximum key age across all keys Session management, enforced MFA, data export controls (Enterprise) Data residency, GDPR tooling, long-term audit retention (Enterprise+) Help us shape this: What kinds of sensitive data are you most worried about accidentally ending up in your logs — API keys, customer identifiers, device credentials, something specific to your domain? Would an IP allowlist be useful for your deployments, or do your controllers sit behind dynamic IPs that would make it impractical? Which of these protections is table-stakes for you to use Anvil, vs. "nice to have eventually"?