Introducing SkySignal: Modern APM Built for Meteor 3.0

Happy to help, been there myself.

Here’s one point in the onboarding which feels a bit broken. You’re asking to add the siteId but there’s no instructions where it can be easily found. I just spent 5 minutes on your app and I can’t find it. I assume it’s in the URL when I click on “Details” but not that this will show the user’s 5 step onboarding instructions and not a detailed modal.

Also, resetting the API keys is hidden too much in the “settings” of another sub-menu, it’s not visible to the user. Just found it by accident but it should be more prominent.

Lastly, wouldn’t it be safer to just refer to the keys like this:

import { SkySignalAgent } from '@skysignal/agent';

SkySignalAgent.init({
    apiKey: Meteor.settings.skySignal.apiKey,
    siteId: Meteor.settings.skySignal.siteId,
});

People will follow instructions and just copy & paste, then unknowingly publish API keys on Git.

Lastly, should be:

meteor npm install --save @skysignal/agent

Getting the following error still:

npm notice Access token expired or revoked. Please try logging in again.
npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/@skysignal%2fagent - Not found
npm error 404
npm error 404  '@skysignal/agent@*' is not in this registry.
npm error 404
npm error 404 Note that you can also install from a
npm error 404 tarball, folder, http url, or git url.
1 Like

We will update the app’s onboarding instructions - the documentation instructions are more up-to-date: Getting Started | SkySignal Docs

1 Like

No problem, Michael. I’ve checked the link and have a question:

Add your keys to your Meteor settings file. Create or update `settings.json

Does that mean that the keys are kept in two files? It’s not clear to me and if so, why is that so. Keeping them in one file should be enough, or not?

As mentioned I’ve ran into problems and as I’m working on that repo right now, have commented out SkySignal for now as the app otherwise doesn’t run.

This looks pretty awesome​:+1::+1::+1:. I’m currently using MontiAPM, but I’d be happy to upgrade to a modern APM built for Meteor 3.0. However, it seems SkySignal is still in beta at the moment? Once I have some time, I’ll carefully evaluate whether it’s worth migrating from MontiAPM to SkySignal. Also, a quick bit of feedback: I entered a random company name, and it doesn’t seem to be editable.

3 Likes

SkySignal February Update - A LOT of new stuff

Hey everyone,

It’s been a really productive month so I wanted to share everything that’s been going on with SkySignal. This is a big one, so grab a coffee.

Dashboard got a major visual upgrade

The main customer dashboard now has 4 new data visualizations that go way beyond the standard line charts:

  • Heartbeat Timeline - Think of it like an EKG monitor for your app. It’s a continuously scrolling line that shows your response latency in real-time, color-coded green/amber/red based on thresholds. There’s a pulsing dot at the leading edge that gives you an instant sense of whether things are healthy. It’s a small thing but it makes the dashboard feel alive.

  • Request Flow Sankey - This one is really useful. It’s a Sankey diagram that shows how requests flow through your Meteor Methods and into downstream operations (database queries, HTTP calls, async work, etc). You can see at a glance which methods are getting the most traffic and what they’re actually doing under the hood. Hover over any link and you get call counts and average durations. Methods with errors get flagged in red.

  • Site Health Heatmap - If you’re running multiple sites, this gives you a GitHub-contribution-style grid where rows are your sites and columns are time buckets. Each cell is color-coded by a health score derived from error rate and response time. It’s great for spotting patterns - you can immediately see if a specific site had a bad hour or if something degraded across all sites at once.

  • Anomaly Constellation - A radar chart that overlays your current metrics (response time, error rate, CPU, memory, requests/hour, sessions) against rolling 7-day baselines. When something deviates significantly, that vertex gets a pulsing red indicator. The center tells you how many anomalies are active, or just says “Normal” when everything’s fine.

All four are fully custom SVG (not a charting library), so they look and feel exactly how we wanted them to. They’re responsive too - they adapt cleanly to mobile and tablet.

New pages: Incidents, SLOs, Runbooks, and Logs

We shipped four entirely new sections:

  • Incidents (/app/incidents) - Full incident management lifecycle. Create incidents, assign severity (sev1-4), track through investigating > identified > monitoring > resolved > postmortem. Each incident has a timeline of events, can link to related errors and alerts, and supports structured postmortems with action items.

  • SLOs (/app/slos) - Define Service Level Objectives for availability, latency, error rate, or throughput. Set your target, pick a rolling window (7d to 90d), and SkySignal tracks your error budget in real-time. You get burn rate calculations and alerting when you’re consuming budget too fast. This was a highly requested feature and it’s something we think every team monitoring a production Meteor app should be using.

  • Runbooks (/app/runbooks) - Operational runbooks for your team. Document step-by-step procedures for incident response, performance debugging, deployment checklists, etc. Each runbook has ordered steps with descriptions, commands, and expected outcomes. They can be triggered manually or configured to fire on alerts and error patterns.

  • Logs (/app/logs) - Structured log aggregation. The agent now captures console.* and Meteor Log.* output from your app automatically. Logs are correlated with traces, errors, and sessions, so you can jump from an error to the logs surrounding it. Full-text search, level filtering, and a 30-day retention window (Pro plan).

Site Detail improvements

A bunch of new capabilities in the site detail view:

  • Trace Waterfall - Click into any method trace and you get a full waterfall diagram showing every operation (DB queries, HTTP calls, async work) on a timeline. It automatically flags N+1 query patterns, slow queries, and unblock analysis. Think Chrome DevTools network waterfall but for your Meteor Methods.

  • Session Timeline - Click into a user session and get a visual timeline of their journey: page flow, events, performance metrics per page, and error correlation. Really useful for debugging user-reported issues.

  • DDP Inspector - A real-time activity feed showing DDP events (subscribes, ready signals, data mutations, errors) for a site. Includes a connection detail dialog and subscription inspector.

  • Versions Tab - Side-by-side version comparison. Select two deployed versions and see deltas for all your key metrics, color-coded green for improvements and red for regressions.

  • Deploy Markers - Deployments are now detected automatically (via GitHub webhooks or agent version change detection) and shown as vertical markers on your time-series charts. Each deployment gets an automatic canary analysis that compares the 15-minute window before and after the deploy, checking latency, error rate, throughput, and new error count. You’ll get a pass/warning/fail verdict.

Change Streams support (Meteor 3.5-beta+)

This is a big one for anyone testing Meteor 3.5-beta+. The agent’s LiveQueries collector now detects the actual observe driver per observer - Change Stream, Oplog, or Polling - by introspecting handle._multiplexer._observeDriver.constructor.name. Previously it used a global MONGO_OPLOG_URL heuristic which treated everything as either oplog or polling.

The “oplog efficiency” metric has been replaced with “reactive efficiency” which is (changeStream + oplog) / total observers. The LiveQueries tab in the SkySignal dashboard reflects this 3-way breakdown.

Anomaly Detection & Observer Leak Detection

Two new background services running automatically:

  • Anomaly Detection - Computes rolling 7-day statistical baselines (mean, stdDev, p95) for your metrics and raises anomaly events when values deviate beyond configurable z-score thresholds. Includes hourly and daily seasonality patterns.

  • Observer Leak Detection - Four heuristic patterns that detect Meteor reactive observer leaks: growing observer counts per collection, long-lived stale observers (>24h with low update rates), inactive observers (zero activity for 30+ minutes), and orphaned observers (outlived their subscription). Integrates with alerts.

Agent improvements (v1.0.12)

  • Log Collection - New LogsCollector that wraps console.* and Meteor Log.* with structured metadata, level filtering, and sampling. You can also use SkySignalAgent.addLog() for programmatic submission.
  • Custom Metrics API - SkySignalAgent.counter(), .timer(), .gauge() for tracking business-specific KPIs. Also a generic trackMetric() for full control.
  • Client-side error tracking fix - Fixed a bug where the server returned 400 “Invalid JSON” when the agent sent batched client errors. The endpoint was trying to read the raw request stream after body-parser had already consumed it. Also added support for the batched { errors: […] } format the agent actually sends.
  • Silent failure for optional packages - If your app doesn’t have the http or email Meteor packages installed, the agent no longer logs warnings to the console on startup. This was confusing for a lot of people.
  • Client IP collection - Method traces now include the client’s IP address for geographic correlation.
  • HTTP Collector performance - Pre-compiled regex patterns, object pooling (50-object pool for request data), and combined exclude patterns for O(1) matching.

Mobile responsiveness

Went through the entire app and compacted metric cards to 2-per-row on mobile (they were full-width before, which meant a lot of scrolling). This applies to the dashboard, overview tab, and all 15+ site detail tabs.

Coming Soon

A few things are built and ready but not publicly enabled yet:

  • Astraeus AI DevOps - Our autonomous AI agent that analyzes errors, fetches your source code from GitHub, generates a fix using Claude, and creates a pull request. The full pipeline is built: a Docker-based worker container that clones repos, creates worktrees, runs Claude Code, and pushes PRs. It supports auto-analysis triggers, post-deploy watch mode, human approval workflows, and rate limiting (20 analyses/day). The UI is complete with a job dashboard, real-time streaming output, and settings panel. We’re doing final testing before enabling this.

  • Integrations - GitHub, Slack, Discord, PagerDuty, email, and custom webhook notification channels are built in the settings view but not yet exposed.

  • Custom Dashboards - Drag-and-drop dashboard builder with configurable widgets (metric cards, charts, data tables, SLO status, error lists, etc). This is built and working but we’re polishing it before release.

  • Infrastructure Upgrades - As SkySignal is close to being ready for production-use, we are in the process of optimizing our hosting infrastructure.


That’s it for now. It’s been a huge month of shipping. If you’re running the agent, update to v1.0.12 for the latest fixes and features. As always, bug reports and feedback go to GitHub · Where software is built.


If you have not tried SkySignal yet – get started in five easy steps:

  1. Sign Up for a free plan at Sign Up - SkySignal APM
  2. Create a new site on the “Sites” page
  3. In your Meteor settings.json file add:
  "skysignal": {
    "apiKey": "YOUR_SECRET_KEY_GENERATED_FROM_SITE_CREATION",
    "enabled": true
  },
  "public": {
    "skysignal": {
      "publicKey": "YOUR_PUBLIC_KEY_GENERATED_FROM_SITE_CREATION",
      "rum": {
        "enabled": true,
        "sampleRate": 1.0
      },
      "errorTracking": {
        "enabled": true,
        "captureUnhandledRejections": true
      }
    }
  }
  1. Run meteor add skysignal:agent
  2. Start using your app and watch metrics populate in your account within a few seconds
6 Likes

What’s the ratio of human code to vibe code here?

PS I’m not judging, just merely curios since I utilize agents a lot in my daily workflow

That is a lot! Looks like I will have to give it a try soon.

To be frank … I am quietly waiting for the OS release of Monti :slight_smile:

Most of my workflow these days is about 90% agent-driven and 10% manual tweaks.

Over the last year, I jumped headfirst into agentic workflows—not just for coding, but for running company ops and all the admin stuff too.

I really think agentic workflows are the future for pretty much everyone, not only devs. That said, they’re not some magic fix-all; they’re just tools that open up the next level of abstraction. What sets things apart is still the thoughts and ideas behind them as agents get smarter.

I’ve put a ton of time into fine-tuning my prompts so that dozens of sub-agents match my coding style almost perfectly now. It helps that I’ve got a bunch of repos and big projects where I’ve written every single line myself (millions over the years), and I use those as examples in the initial prompts.

Funnily enough, that’s why I kicked off SkySignal—I nailed a fully agentic setup for local dev and wanted the same solution for DevOps.

My advice to folks: Don’t shy away from AI or agentic workflows.

  • Be super clear with your prompts—lay out the strategy like you’re explaining it in a casual chat or jotting down a plan.
  • Think of agent coding as the next step up in abstraction.
  • Remember, it’s still just a tool—your success depends on how you use it.
  • Agent-generated code doesn’t let you off the hook; humans are always accountable in the end.
  • Always read through the code the agent spits out—review it like an editor, even if you’re not writing it from scratch.
  • I feel like “vibe-code” kinda undersells what agentic workflows can do. It lowers the entry barrier, which is awesome and makes dev more open to everyone. But yeah, that also means there’s a bunch of sloppy “vibe-coded” projects out there. At the end of the day, it’s the user who makes or breaks it
4 Likes

Just installed - Thank you, this is really generous for the free tier. Setup was seamless.

I think the only feedback I have is - how do i get in to dark mode like on the homepage :crazy_face:

1 Like

Can this run alongside Monti or it’s one or the other ?

Any plans to add BullMQ to your supported jobs?

BullMQ +1
I also use this one. :grinning:

Added BullMQ support to the roadmap.

BullMQ +1. It’s one of the most used queue systems in meteor world. probably because of redis-oplog

Who isn’t using BullMQ these days. It’s a life saver, would love to go Pro but their pricing is just ridiculous (for getting “groups” which is the feature I’m mostly interested in).

Having said that, I’m using the BullMQ dashboard in my Admin app and I have added statistics to see how long certain types of jobs are running and some other important stats on the queues (for me).

So wondering what exactly you guys want to see added to SkySignal in terms of BullMQ?

Hear, hear. Fully agree with you. As good as we are as humans, we can never be top notch in everything that a small software company has to offer (as jobs). Hence the Agentic AI comes in very handy. I also don’t need to read through endless pages of documentation to get things done that I’ve never done before (especially on the engineering side).

On that “vibe-coding” topic I think we need to distinguish clearly between “vibe-coding” - which is what these YouTube ads tell you “I don’t know how to code but I’ve just build an app/website” vs Agentic AI for coding. That’s a huge difference as we all know and the only common thing is the word AI in both :wink:

Just my two cents and keep up the good work @mvogt22 - this is some huge progress and some excellent new ideas that you brought to live. Excited to read about your agent Astraeus AI DevOps - that sounds the most promising thing so far.

2 Likes

So wondering what exactly you guys want to see added to SkySignal in terms of BullMQ?

My use case is pretty simple—I just need a simple interface to check queue info (like how many jobs are executed per day). :grinning:

That’s exactly what I let AI build in 15 minutes:

Customize it to your liking.

I’m not 100% convinced that such should be “automatically” be on SkySignal. The package will become bloated if the next person is then requested “Oh, I use Steve Jobs as a queue system, please add it as well” and so on.

Just my two cents :wink:

@mvogt22 check this out: Software engineers are going to love this! (open-source, 95% less production downtime) I found an open-source error monitoring agent that scans production logs, finds the root cause, and sends a… | Akshay Pachaar

1 Like

This will be Astra AI (renamed from Astraeus) but dedicated for Meteor apps. Very cool to see!

1 Like

What you’re showing there is similar to what you can get with bullboard - you should try that out.

What we’d like to see in skysignal is more like what’s in monti APM - each job execution is fully instrumented like a method or publication so you can see everything in detail. Along with the typical stats like throughput / duration.

1 Like