AppBeat Blog

Perfect Monitoring for Your Cloud

Coming soon: recurring unmonitored time functionality

Soon you will be able to define recurring time periods when service and all its child checks will be temporary excluded from monitoring:

This may be useful for some customers who don't need 24/7 monitoring and don't want to use our API integration to pause / resume service with web services.

New feature will be added as part of our 1.8.0 application version upgrade in it is scheduled to be publicly available in beginning of 2018.

Stay tuned :)

Receive huge website monitoring discounts!

Website monitoring discounts are now available:

  • receive 50% discount when switching from another monitoring provider
  • receive up to 90% discount for recommending AppBeat on social media or web page
  • recommend AppBeat to another user / company and receive free credit upon their purchase

Please contact us for more details!

Note: discounts can not be combined

How to create public status page for your domain or service?

Want to share your latest monitoring status with your users? Want to notify your visitors about scheduled maintenace /downtime? You can do this very easily with AppBeat:

  • login to your AppBeat account (or create one for free)
  • click on "Public status" and then "Enable public status page"
  • configure if you want your status to be automatically updated by AppBeat (and for which monitored services)
  • your public status can then be hosted on:
    • your web server / your domain by copy/pasting our high-availability JavaScript snippet on your page
    • our web servers / our domain (
    • for Advanced plans and higher: we can host your public status on our AWS infrastructure (yearly plans can also have free certificate for secure HTTPS version of public status page) - please contact us so we can send you instructions for DNS entry on your domain


Have questions? Please let us know.

How to get notification before SSL certificate expires?

Login to your AppBeat account (or create new one if you don't have it yet).

Click "Add new periodic monitor" and select "SSL Certificate" as shown on screenshot below:

Click "Next" button and enter your URL:

Click "Next" and close wizard with "Finish".

Your certificate will now be periodically monitored and when it is about to expire (30 days or less - you can change this in check settings), you will automatically receive notification (we support email, SMS, Slack, web hooks, ...).

Simple as that!

Migration of our monitoring stack to .NET Core 2.0 and .NET Standard 2.0

After successful migration of our monitoring front-end, back-end and microservices to .NET Core 2.0 and .NET Standard 2.0, here is quick summary of this process.

Migration decision

Although we were very very satisfied with .NET Core 1.0, we decided for migration to newest version for following reasons:

  • bigger API and more libraries available (thanks to .NET Standard 2.0)
  • much easier to share common internal projects between .NET Core 2.0 and Full .NET Framework on Windows (.NET Framework 4.6.1 and newer)
  • security and performance improvements


We started official migration from .NET Core 1.0 as soon as Microsoft released RTM version of .NET Core 2.0 and Visual Studio tooling. Entire process went quite smoothly and without major issues. We followed official instructions published on Microsoft Docs (very useful).

During migration, most time was spent for resolving NuGet conflicts and we also encountered one runtime problem with Entity Framework Core 2.0 - we resolved this by doing simple workaround and rewriting this one problematic query. Everything else was - perfect!


Our migrated solution is now deployed on Windows and Linux production servers and everything runs without any issues. Improvements on web front-end are very noticeable (Kestrel, compiled MVC views, smaller deployments). Mission accomplished!

Thanks to Microsoft and all open source contributors for making such a great product!

Want less monitoring alarms? Introducing quiet hours!

In newest AppBeat version 1.7.0 you can now define quiet hours for your users, services and/or third-party integrations (I will refer to these as "resources").

Quiet hours are recurring time periods during which alerts (outgoing notifications) are muted for selected resource(s). Quiet hours does not affect monitoring, just notifications. This means that you will always be able to check log entries, even during effective quiet hours.

You can access this new feature from "Alerting" module and by clicking "Quiet hours" tab as shown below:

When you click "Add quiet hours for" button for specific resource, you will be presented with dialog similar to this:

You can add multiple quiet hours for same resource, AppBeat engine will always aggregate those entries while determining if quiet hour is effective or not.

Here are some use case examples:

  • you have service which is not operational 24/7 - now you can simply set quiet hours when service is not active so you don't receive any alerts
  • you have recurring (nightly) updates and you want to mute alerts during this period
  • you don't want to receive alerts for less important service(s) during weekend
  • your team member goes on vacation or sick leave and you don't want to bother him/her with outage alerts
  • some of your team members receive alerts only during working hours (and you have dedicated team for 24/7 operations)
  • etc.

Happy monitoring!

Implementing WebDriverIO support in .NET Core 2.0 for efficient Selenium testing

We are currently implementing experimental subset of WebDriverIO API (higher level API on top of Selenium WebDriver) in .NET Core so we could run synthetic (transaction) monitoring very efficiently from different geographic locations.

Implementation goals:

  • cross-platform, efficient and lightweight framework
  • easy to use (REST API / web interface)
  • high compatiblity with WebDriverIO because users are already familiar with it
  • for security reasons we will probably implement simple JavaScript interpreter for WebDriverIO commands (instead of running tests in Node.js)

Currently we have basic prototype but it looks very promising:

If you have any ideas or suggestions, please let us know!

New notification rules for website monitor

We slightly updated our notification rules for new website checks. Reason for this update is only "cosmetic" - new rules will generate better descriptions for outgoing notifications and log files.

New rule for status "Error"

[trigger_rule: 5xx server error rule]
%STATUS% >= 500

[trigger_rule: 4xx client error rule]
%STATUS% >= 400

New rule for status "Warning"

[trigger_rule: warning by 3xx redirection rule]
%STATUS% >= 300 AND %STATUS% < 400

New rule for status "Good"

%STATUS% >= 200 AND %STATUS% < 300

Previously we included 3xx redirections in status "Good", but now we moved them to "Warning" rule. Error rule is now also more detailed.
Of course you can update default rules to suit your own needs and combine them with other variables (%RESPONSE_TIME%, %RESPONSE%, %RESPONSE_HEADER%).

Please note: rules are always evaluated from top to down in following order: Error --> Warning --> Good. When first condition is met, rule evaluation is stopped and status is returned.

Rules for existing web checks were not changed. Users can optionally updated them if they choose so. Please contact us if you have any questions.

Improved user experience for our website monitoring client

We published new web application with improved UX and some new useful features:

  • you can now quickly filter your checks on "Live status" screen:

  • added quick actions for monitored checks and services

  • "Live status" simplifications due to new quick actions feature
  • Check wizard should now have better support for high DPI displays and show vertical scrollbar where needed
  • Added option to easily clone monitored check (this allows you to quickly create similar monitors)

  • "Live status" - dismiss all alerts is displayed when there is more than one service alert. Previously you had to click "dismiss alert" for each monitored service.
  •  new API methods: added dismiss-service-alert and dismiss-all-service-alerts endpoints
  • other minor improvements & optimizations

If you find any issue please let us know.

Happy monitoring!

Receive monitoring alerts to your Workplace by Facebook

Today we published new application version with native support for Facebook Workplace.

How to enable it? Please login to your Facebook Workplace account with administrative rights.

Click on Dashboard / Integrations and click "Create App" button. Enter "App Name" (it can be AppBeat or something similar) and set minimum App Permissions to: "Read content" (needed to read group id) and "Post to groups" (needed to post alert).

Now go to AppBeat and click "Alerting" from left menu. Select "Third-Party service integration" tab, click "Add new integration" button and select "Workplace by Facebook":

Please enter following fields:

  • arbitrary integration name (seen only in AppBeat)
  • access token (you should get this when you create Workplace App as described above)
  • community id (available from Facebook Workplace Dashboard / Integrations)
  • group (group name which is available in Facebook Workplace; you can also leave default group named "General")

We suggest that you click "Test" button and check for any errors. If everything goes OK, you should see new test post in your Workplace group.

Finally, don't forget to associate your new Facebook Workplace integration with your AppBeat service. You can do this by clicking "Services & Checks" from left menu, double-click on service that you want to link, select "Notification types" tab, enable (check) your new integration and click "Save" button.

Optionally you can repeat this for multiple services.

Hopefully you will find these instructions useful. And as always - happy monitoring!