Operations | Monitoring | ITSM | DevOps | Cloud

Fly.io is a neat choice for deploying Django fast and globally. What it doesn’t really give you out of the box, though, is a deeper picture of an application’s performance. Deployment is only part of the story. No matter which platform you’re using, operating a production application means you need to understand how it behaves. AppSignal helps you fully grasp what happens on the Fly.io server.

Like it or not, vibe coding is here to stay. It’s too easy to just go away. Maybe if the per token cost rises too much at some point that it becomes cheaper to hire a junior… But until then, you’d better get used to it. For now, tools like Cursor, Copilot, and Claude let developers (and plenty of non-devs) ship full-stack apps faster than a junior is able to completely grasp the concept of the app they’re working on. And that’s pretty neat.

Good monitoring shouldn't be a luxury for well-funded teams. Early-stage startups run the same production systems as everyone else, on a tighter budget. That's when clear observability earns its keep. Today we're launching AppSignal for Startups: an ongoing discount on the full AppSignal platform for early-stage teams, with a better deal for Y Combinator companies.

Good news for PHP developers: AppSignal monitoring is now available for PHP applications. Our new package brings traces, metrics, and logs from your PHP app into AppSignal, with auto-instrumentation for frameworks like Laravel and Symfony and a foundation built on OpenTelemetry. Already using AppSignal's PHP package and want the latest updates? Migrating is straightforward: remove your current OpenTelemetry setup and follow our new install guide.

Prometheus is a battle-tested, flexible and, most importantly, free tool that has long been the go-to open-source monitoring solution. Much of its popularity came down to its simplicity. A few years have gone by, though, and the APM space has gotten pretty crowded. Developers are now starting to move away from the complexity of self-hosting, and OpenTelemetry stands out as one of the CNCF’s fastest-expanding projects. In fact, it’s now among the most adopted telemetry frameworks out there.

Performance problems in Rails applications are sneaky. Generally speaking, nobody opens tickets that say “my application is slower than it was last month (about 20%)”. What you do get instead are vague complaints from team members about a p95 latency that is climbing every week or a background job that used to take 2 seconds now taking 40 seconds to finish.

You open a monitoring tool, and the data is all there: errors, traces, anomalies, incidents, and countless intricacies. If you want to get the right slice of that data, you need to know exactly which dashboard to open and what filters to apply. But when the poor UI gets in the way, this can take longer than it should. Luckily, this is not the case with AppSignal. MCP (Model Context Protocol) changes the interface entirely.

AppSignal now supports Render's Metrics Stream. Configure it once in your Render workspace and Render forwards OpenTelemetry metrics to the AppSignal Collector. From there, the metrics show up in your AppSignal app as host metrics and automated dashboards. You only have to set up the stream once per workspace.

AWS delivers CloudWatch metrics in OpenTelemetry format via Firehose, but AppSignal uses its own internal format. Building the parser to bridge these two formats presented several technical challenges. The metrics arriving through this pipe power AWS automated dashboards. When AppSignal detects metrics from a supported AWS service, it creates a dashboard for it automatically, with pre-built charts grouped by category: compute, databases, networking, messaging, storage, and others.

A lot of what's useful in a high-volume log source is a count, a rate, or a measurement — 5xx responses per minute, p95 request duration, job retry rate. You don't need every line to track those. You need the metric. Log-based metrics is now in beta as part of AppSignal Labs.