Something is wrong — but how do you know? Enter monitoring and alerts.

Monitors are automated processes which mobile teams use to track their mobile applications. Traditionally, developers build in-house tools for monitoring that which they care about: downtimes, loading times, resource consumption, etc.

The problem is: time spent building a monitor is time not spent on building features!

Embrace saw that developers were struggling and said: “Well, since mobile teams are often tracking the same things, we’ll just build a tool that tracks these things for them."

And mobile teams rejoiced.

Then we looked at our tool and said: “OK, now we’re going to make our tool track all the things possible so mobile engineering teams can now track anything they want.” And thus Embrace’s monitoring tool was updated. Powerful stuff in the hands of companies that care about data and tracking. Too powerful in the wrong hands, our engineers said.

All was fine. Until things were going wrong.

“But how?!” exclaimed mobile teams, “We’re obviously tracking them with monitors!”

Which is fine and dandy until an engineer poked their head into the monitoring systems and said: “Ah, the monitors are working. They just aren’t telling us when something is wrong.”

Alerts were then configured and added to the monitoring systems so all VPs could breathe a sigh of relief. Finally! The dreaded rousing call that would summon engineers to fix things was configured. To make it easier for the engineering team, these monitoring systems were also given a dashboard for visualization of what was happening.

All was fine. Until things were going wrong.

“But how?!” exclaimed mobile teams, “We’re obviously tracking things with monitors and have alerts set up to notify us when things go wrong! We’re looking at the dashboard now — and there’s nothing wrong!”

Which is fine and dandy until an engineer poked their head into the system and said: “Ah, the monitors are working. The alerts are working. The dashboard is displaying everything we care about. We just didn’t think of tracking everything else and being alerted about things we didn’t know about.”

Here’s What’s New from Embrace: Proactive Monitoring!

What Is It?

These are proactive alert configurations mobile teams can use to catch unanticipated issues as soon as they appear. Now a mobile engineer doesn’t need to fix things after the entire userbase knows it’s broken, but instead can do preemptive damage control. (Note: Alert Time and Break Time may vary based on personal experience)

Why Should Mobile Engineering Teams Care?

In an ideal world, mobile teams know everything that’s going on in and around their app. That knowledge then translates to the ability to configure monitors for everything they want to be alerted about. Unfortunately, in mobile you cannot predict all the issues.

  • The backend team adds new endpoints the frontend team didn’t know about.
  • Third-party SDKs (like Facebook) have failing network calls that crash your app.
  • 200 calls might not return all the data if there was a connection error.

Proactive monitoring exists as a catch-all safety net for detecting crashes, bugs, etc. that the mobile engineering teams did not or were not able to plan for.

Traditionally, there’s the whitelist alert method: the engineering team decides they care about XYZ items when ABC problems occur with “oh-no-no-no” frequency. So they painstakingly write a deterministic ruleset for being alerted that “oh-no-no-no” is about to happen (or worse, currently happening) so that the engineering team can order a drink with extra double triple shot of caffeine while they look at what’s wrong.

This whitelist method works until it doesn’t; the nature of this method means that the engineering team needs to know ahead of time what they are configuring the alert for. So what happens when something they don’t know is breaking? The whitelist method isn’t designed to monitor that!

So Embrace designed an additional safety net that monitors very generic issues that engineering teams care about. This safety net is cast extremely wide and is designed to alert the team whenever any metric is worth noting.

But I’m worried that now I'll get too many alerts…

The reason this “blanket safety net” solution wasn’t used traditionally is because it treats everything that comes up as a problem — even if it isn’t actually a problem.

So Embrace came up with a solution.

Embrace knows: engineers don’t want to be getting a ping each time something goes wrong. They want that alert to only go ping when what’s currently going wrong is approaching/has gone past a threshold that they already set.

With Embrace’s proactive monitoring, you can:

  • Set threshold percentages and minimum counts for alerts to trigger on.
  • You can customize these settings for 4xx, 5xx, and connection errors.
  • You can blacklist any domains you want (e.g. ones that you’ve set previous monitors for or ones that you no longer want to track).

In other words, you can set up alerts to the level of granularity that works for your team. So in addition to customizing the targeted alerts you want, with Embrace you can also control how and when you want to be notified when the things you hadn't accounted for go wrong.

How Embrace Helps Mobile Teams

Embrace is an observability, monitoring, and developer analytics platform built for mobile teams. We are a one-stop shop for your mobile app’s needs, including error debugging and monitoring app performance and feature releases.

Want to see how Embrace can empower your mobile team to identify and solve every issue before it gets out of hand? See how highly targeted and proactive monitoring can reduce your TTI and TTR to minutes instead of days.