FAQs

You guessed it — frequently asked questions!

General Questions

Is Skylight compatible with other profilers and monitoring tools?

Skylight plays nice with other profilers and monitoring solutions, including New Relic. Many of our customers run multiple tools with success! Go ahead and compare :)

Reading Skylight

What is the “Rack” endpoint?

Skylight measures the time spent in Rails actions, and most of the time, your requests end up making their way into Rails actions eventually. Once a request makes its way to an endpoint, Skylight tags the request with the endpoint’s name. However, it is possible for Rack middleware to intercept the request and return a response without delegating to an endpoint. When this happens, Skylight uses the generic “Rack” name for the request, and in practice, these requests tend to be very fast. With the 1.4.0beta agent, you can enable the middleware probe to show individual middleware in your Event Sequence.

There are a number of different reasons why you might see “Rack” listed in your Endpoints List. For example, Rack::Cache may be intercepting your request when your app gets a cache hit. Another example is ActionDispatch::Static, which is an interesting case. This middleware handles requests in the /public folder and acts as an endpoint for static files. While it is not a Rails action, it does behave quite similar to a Rails action: it uniquely handles a particular URL and returns a result.

What does it mean when the “rack.request” event is slow?

In Rails apps, “rack.request” will usually be the first item listed in the Event Sequence. This event represents the time spent before the actual Rails controller action is hit. Usually this event has minimal self-time, but some middlewares may cause slowdowns in the “rack.request” event. With the 1.4.0beta agent, you can enable the middleware probe to show individual middleware in your Event Sequence. If you don’t want to upgrade to the beta, you can run rake middleware to see a list of your middleware and do some detective work to determine which middleware is the culprit.

Security

Skylight follows generally acceptable security practices. Most importantly, we don’t store any sensitive data ourselves.

What data does my app send to Skylight?

When you install the Skylight agent in your app, it will send the following information to our servers:

  • Endpoint names (without parameter values), e.g, what’s in rake routes
  • Generic descriptions of different items in your call stack
  • Sanitized SQL queries (see below)
  • Response times
  • Generic metadata about your application such as OS and framework version.

Will my users’ private data be sent to Skylight?

Nope. All performance metrics are scrubbed of private data by the agent running on your server before anything is ever sent our way. Skylight doesn’t collect sensitive data like request param or database query values.

In fact, scrubbing parameters and values from the data your app sends is what allows Skylight to aggregate your data, providing you with an accurate view of your app’s performance on the whole.

For example, Skylight will remove variables from your SQL queries and display aggregated queries in the UI along with average durations and allocations:

Screenshot of a sanitized SQL query

Can I read your privacy policy?

Sure! You can find our Privacy Policy here.

GitHub Integration

Why do you need read and write access to all my repos?

If you signed up for Skylight using GitHub, you may have seen this before:

Github permissions

We don’t really need write access to your repos, nor do we use it. We just want to check all the repos you have access to (public and private) to see if there are any apps on Skylight that are attached to those repos so we can give you automatic access.

Unfortunately, GitHub OAuth does not offer read-only access to public and private user repos (you can see the scopes they offer here, so we have to ask for read/write access even though we’re really just reading.

What about organizations?

We also request read-only access to your organizations. This is so you can choose a repo belonging to a specific organization in order to attach it to your Skylight app. There is more information about this here.

What if I add or remove someone from a repo that’s connected to Skylight?

If someone is added to a repo, they should have access to the app on Skylight as soon as they log in with GitHub.

We run a daily check to make sure everyone’s access is exactly as it should be. If someone’s repo access is removed, their Skylight access will be revoked when we run that check.

I’m having a different issue involving the GitHub integration.

Check out the GitHub section of our Troubleshooting page. If you don’t see your issue there, feel free to email us at support@skylight.io and we’ll help you out!

Feature Requests

How do I get access to beta features?

Accessing User Interface Beta Features

The easiest way to gain access to Skylight’s UI beta features is to become a Skylight Insider. It’s super easy. Just head to your account settings page and click on the Insider postman (although some Tilde employees claim he is actually the Skylight Code Deputy) to cement your status. Once you’ve become an Insider, you can toggle beta feature flags on and off to your heart’s content.

Animation of how to become an Insider

Read more about our feature toggles here.

Accessing Agent Beta Features

Message support@skylight.io or contact us via the in-app messenger to see if your app is a good candidate for helping us test new agents and new agent features.

Can I get alerts when my performance changes?

While we don’t yet give you up to the minute alerts, you can get insight into your app’s weekly changes by signing up for Trends emails in your account settings. Down the road, we may add more immediate alerting when significant slowdowns occur in your app.

Can I track deploys?

Soon! We’ve got work underway to make this happen. Sign up for our Insider emails in your account settings to get the latest scoop on development.

Can I instrument background jobs like Sidekiq?

Background job instrumentation is a high priority for us. The technical aspect of it isn’t too hard, but the big blocker is the UI. We don’t just want to throw the background jobs into the regular UI since in most cases, they’ll take much longer than normal requests and won’t have the same immediate impact on the end-user.

But, we ourselves use Sidekiq and agree that it would be great to have more insight into our background jobs performance.

Can I administer my apps with organizations?

Not yet, but it’s something we’ve got on our roadmap. Our current thought is something based around GitHub organizations. If you’ve got any thoughts on this, we’d love to hear them.

Do you plan to add error tracking?

Right now we’ve chosen to focus on providing you the most useful performance information we can. That said, in the future we’d love to provide some basic notifications, especially around increased error rates. For more robust error tracking, we recommend a dedicated tool like Bugsnag.

Can I view more than one day’s worth of data at a time?

Yes, you can, via the Trends email, which you’ll get after your first two weeks of using Skylight. The Trends email shows the last six weeks of your application’s performance.

Showing weeks and months of data on demand is not as simple as it might seem. We use a technique that many time-series databases use called pre-aggregation. This means that we store all your data collated into timeslices. Timeslices make it possible to fetch arbitrarily large time ranges or time ranges that are not simply aligned to the day or hour.

At this stage, we haven’t been pre-aggregating data past one hour sizes. This means that if we were to query for a two month period, we’d need to make 24 x 60 queries to fetch the data. This can quickly escalate to 100s of 1000s of queries for a single application.

Can I cap the number of requests that I send to Skylight?

Alas, there’s no way to set a limit or cap right now. This was possible in the very first version of Skylight, and contrary to our expectations, more people disliked it than found it helpful.

It turned out most of our users were already accustomed to usage-based services since they were already using them for things like hosting (Heroku, AWS, etc) and other parts of the stack. When we had the ability to set a limit, people would set it aggressively low in an effort to be frugal and then get annoyed by the notifications when they consistently hit those unrealistic thresholds. While we’re sure some people would still appreciate it, overall it made significantly more people unhappy than happy, so we didn’t build it into our next version.

It’s also worth mentioning that Skylight is most accurate when reviewing aggregated requests over a longer period of time, so by capping your requests and not giving Skylight all the information available, you may end up on some wild goose chases.

Do you have this feature that New Relic has?

New Relic has lots of features we don’t have but, in our opinion, they’re not all that useful. We’ve decided to focus on making sure that everything we show you provides immediate value. Our customers find that it’s easier to make sense of our UI and to get actionable information from it. Sure, we could throw more stats in, but sometimes less is more.

I’ve got a different question.

We would love to hear your questions. Just shoot us an email at support@skylight.io or use the in-app messenger (“?” in the bottom right of the web UI). See our section on Submitting Feedback for more details.